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:
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.
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:
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)
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp)
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
Created attachment 134056 [details]
getFreeSpace source code
I wrote a function that makes the control of free space for Linux systems via statvfs and I wrote the part of the function that got as a full path of ~/.config. What is the next step?
This will be my first commit. I'm happy if you help me.
Oh nice; so we need to create a new method in sal/ that allows us to detect how much free space there is available at a given path I guess; Stephan is a great guy to give a code-pointer for that and an API name recommendation (we're very careful about sal/ API changes). We'll also want no-op implementations for windows / Mac to start with too.
Then of course you'll want to use that method inside sfx2/source/doc/sfxbasemodel.cxx - search for impl_store for a good place for that - to throw up a warning dialog for low disk-space scenarios.
I'd also love to see a low priority, very idle handler every 30 seconds or so that looks at the temporary directory we store our images, stuff in to check we have enough /tmp space to function reliably - ideally checking at startup too for this. But lets get the method in sal/ sorted out first.
In include/osl/file.hxx, there's already osl::Directory::getVolumeInfo and osl::VolumeInfo::getFreeSpace. While getVolumeInfo's ustrDirectoryURL parameter is documented as "Full qualified URL of the volume", the statfs-based implementation in sal/osl/unx/file_volume.cxx will apparently accept any path into a mounted filesystem, and the Windows implementation in sal/osl/w32/file_dirvol.cxx explicitly does some path_travel_to_volume_root, so it should work in practice to pass an arbitrary path into a "volume", not just a path to a "volume root".