Bug 61255 - FILEOPEN: File opening shows that file is corrupted when /tmp is full, locked file afterwards
Summary: FILEOPEN: File opening shows that file is corrupted when /tmp is full, locked...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Blocks: Desktop-Environment
  Show dependency treegraph
Reported: 2013-02-22 00:41 UTC by Rodolfo Quesada
Modified: 2018-10-26 23:26 UTC (History)
0 users

See Also:
Crash report or crash signature:

LibreOffice Error when opening a file and /tmp is full. (5.46 KB, image/png)
2016-04-16 19:26 UTC, Rodolfo Quesada

Note You need to log in before you can comment on or make changes to this bug.
Description Rodolfo Quesada 2013-02-22 00:41:32 UTC
Problem description: I tried to open a spreadsheet file unaware that my /tmp directory was full (a ramdisk), so LibreOffice showed me a dialog that said that the file is corrupted and it should attempt to fix it and to not trust the contents afterwards. It was unable to do so. 

I cleaned my /tmp directory and then proceeded to copy the file to another location and it opened without any issue and intact details. 

Also, a ".lock....name_of_file" locked the filename in the directory and I needed to remove it manually in order to have a file with the same name as the locked file. 

Steps to reproduce:
1. Fill the /tmp partition/directory (this is common in distributions as ArchLinux that uses a ramdisk, otherwise the hard drive should be full)
2. Open a file
3. Errors will appear and the .lock file should be removed manually. 

Current behavior: A lock file blocks the manipulation of a file with the same filaname in the same directory. LO says that the file is corrupted but it isn't. 

Expected behavior: It shouldn't say that the file is corrupted if the error is LO unable to create a temporary file in /tmp (I guess that's what happened). A lock file should be removed if there isn't an open session. 

Thanks for a great product and the amazing work you guys have done!

Operating System: Linux (Other)
Version: release
Comment 1 Michael Meeks 2013-03-01 18:44:22 UTC
I've seen problems like this when low on space. There are so many potential failure modes - that IMHO we should check free-space and warn before doing any load/save of this kind - as well as improving this warning.

Thanks for the report :-)
Comment 2 QA Administrators 2015-02-19 15:34:53 UTC Comment hidden (obsolete)
Comment 3 Michael Meeks 2015-03-07 17:04:32 UTC
Not sure if it's still alive; but we should certainly have some unit tests for this scenario - hopefully we can simulate them in various ways.

Perhaps there is some better way we can warn people of low-space on our /tmp folders - if it's sub size-of-document*2 or something then there is likely to be an issue.
Comment 4 tommy27 2016-04-16 07:24:22 UTC Comment hidden (obsolete)
Comment 5 Rodolfo Quesada 2016-04-16 19:26:23 UTC
Created attachment 124414 [details]
LibreOffice Error when opening a file and /tmp is full.
Comment 6 Rodolfo Quesada 2016-04-16 19:32:39 UTC
Bug is still present in: 

Build ID: Arch Linux build-1
CPU Threads: 4; OS Version: Linux 4.5; UI Render: default; 
Locale: en-US (en_US.utf8)

How to reproduce: 

1) Fill /tmp (dd if=/dev/zero of=/tmp/zero.zero)
2) Try to open any file in LO
3) Error will appear (attached to thread).
4) Clear /tmp
5) Try to open the same file, it is now locked
6) Remove .~lock.<filename>.odt# 
7) It works again
Comment 7 QA Administrators 2017-05-22 13:25:17 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice 
(5.2.7 or 5.3.3  https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and 
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave 
a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)


2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword

Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team