Bug 60909 - Out of space warning ...
Summary: Out of space warning ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) release
Hardware: Other All
: medium normal
Assignee: Hassan Sajjad
Whiteboard: reviewed:2022
Keywords: difficultyInteresting, easyHack, skillCpp
: 152914 160604 (view as bug list)
Depends on:
Blocks: Desktop-Environment
  Show dependency treegraph
Reported: 2013-02-15 16:15 UTC by Michael Meeks
Modified: 2024-04-09 23:59 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

getFreeSpace source code (844 bytes, text/plain)
2017-06-15 23:46 UTC, drX
Error message when no disk space is available (31.40 KB, image/png)
2023-01-10 21:13 UTC, Hossein

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2013-02-15 16:15:48 UTC
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 !
Comment 1 Michael Meeks 2013-02-15 16:20:25 UTC
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.
Comment 2 Björn Michaelsen 2013-10-04 18:48:04 UTC
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
Comment 3 Robinson Tryon (qubit) 2013-10-23 16:49:38 UTC Comment hidden (obsolete)
Comment 4 Robinson Tryon (qubit) 2015-12-14 05:03:42 UTC Comment hidden (obsolete)
Comment 5 Robinson Tryon (qubit) 2016-02-18 14:51:58 UTC Comment hidden (obsolete)
Comment 6 drX 2017-06-15 23:46:12 UTC
Created attachment 134056 [details]
getFreeSpace source code
Comment 7 drX 2017-06-15 23:48:22 UTC
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.

Comment 8 Michael Meeks 2017-06-19 09:35:06 UTC
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.

Thanks =)
Comment 9 Stephan Bergmann 2017-06-19 10:02:59 UTC
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".
Comment 10 Hossein 2023-01-10 21:13:51 UTC
Created attachment 184569 [details]
Error message when no disk space is available

Re-evaluating the EasyHack in 2022

This issue is still relevant. I ran Michael's instructions, then invoked the below command after filling the disk space. As a result, I got an error message that is provided here as an attachment. But, no warning message is shown when I have some small disk space which is < 1 MB.

$ instdir/program/soffice -env:SAL_USE_VCLPLUGIN=gen -env:UserInstallation=file:///tmp/small /tmp/small/1.pptx

While having < 1 MB disk space, I get this warning in the terminal, but not when the space is between 1 and 2 MBs.

warn:configmgr:57868:58063:configmgr/source/components.cxx:190: error writing modifications com.sun.star.uno.RuntimeException message: "cannot write to file:///tmp/small/user/nnePqE at ~/Projects/libreoffice/core/configmgr/source/writemodfile.cxx:109"

Please note that both the profile and the opened file were inside /tmp/small.
Comment 11 raal 2023-01-22 13:12:09 UTC
*** Bug 152914 has been marked as a duplicate of this bug. ***
Comment 12 Justin L 2024-01-09 19:15:31 UTC
I imagine blocking on this could end up badly in btrfs volumes or anything that deduplicates, snapshots, or tends to provides "guesses" on how much free space is available.
Comment 13 Rafael Lima 2024-04-09 23:59:33 UTC
*** Bug 160604 has been marked as a duplicate of this bug. ***