LibreOffice does really rather a bad job when space starts running low, in particular without enough /tmp directory space or ~/.config/libreoffice space for the backup file, or of course space in the destination we tend to mangle the document and give a horribly unhelpful warning (if you're lucky). So - we should really check for free space before saving with some suitable margin of error. A good place to add a hook like that might be: sfx2/source/doc/sfxbasemodel.cxx /impl_store/ And of course the "get free-space available on these paths" method needs to go into sal/osl/ somewhere - with a unx/ variant and so on. I suggest we pass a vector down into there of paths and spaces we need on each path - since they could be on different devices - no point in reserving 3x the space on each device. Ideally we should estimate what the size of our data will be - that is rather hard, initially at least ensuring there are several Mb free would prolly do the trick. Thanks !
Oh ! and ... there is another thing that is perhaps worth doing first. Sometimes writing a document fails - and it produces a zero-byte document - we should prolly check in these cases for this condition and suggest out-of-space as a potential cause (I was caught out by this). I guess it's worth finding / testing that on a Linux machine with a small ram-disk: mkdir /tmp/small sudo /bin/mount -t tmpfs -o size=20m,mode=0700,uid=$USER,gid=$GROUP /dev/shm /tmp/small should make a 20Mb ram-disk to play with.
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Removing comma from whiteboard (please use a space to delimit values in this field) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.