Despite multiple saves, file does not exist

English
, , ,
#1

In brief: ctrl-s and shift-ctrl-s fail (and give no warning) after localc recovers a file followed by power outage

=============

To summarize, after a power outage & localc recovery of file, localc defaults to saving files in /tmp/lu-hash (instead of its normal default behavior of saving files in the directory from which it was run). Even worse, it fails to save them there and gives the user no warning of failure. This is true for both ctrl-s saves and for shift-ctrl-s save-as dialog saves.

In Tools > Options > Load/Save > General
Save AutoRecovery information every is set 10 minutes.
Always create a backup copy instead is unchecked

Note that LO 26.2 Help omits the word ‘instead’.

I’m running LO 25.8.4.2

=============

Yesterday I was editing version 12 of my spread sheet, fn.012.ods. As my work progressed, I kept incrementing the version numbers, as is my habit. While I was editing version 16, fn.016.ods, we had a ~1/2 second power outage. This caused, essentially, my computer to be unplugged while running. This happened because I at some point switch the power cord from the UPS to a strip and forgot to switch is back. Stupid me.

After rebooting, I opened the file with localc fn.016.fn on the commandline, as is my habit. Localc asked if I want to try and recover recent changes. I agreed. The recovery succeeded. I didn’t loose any work.

I continued working for another couple hours during which time I began saving it is as version 17, fn.017.ods. I thought these save’s were being made into my project directory, the directory from which I had opened localc. Localc has always placed all save-as’s and save’s in that directory automatically. I’ve never had to navigate in the save-as dialog to the project directory.

This morning, I sat down only to discover that version 17 is not in my project directory. The directory contains versions 16, 15 ,14, … 2, 1, but not 17. Version 16 timestamp predates the power outage.

The most recent file in ~/.config/libreoffice/4/user/backup/ is version 14.

I searched my entire disk, find / -iname “*fn.017*”. I’ve been unable to locate version 17 anywhere …

… except In File > Recent Documents, where it is listed along with 24 other files.

However when I click to open version 17, localc says it is trying to open /tmp/lu379312329/fn.017.ods but says that file does not exist.

File > Recent Documents > fn.016.ods opens fine (it’s location in is my project directory). However despite multiple ctrl-s saves it does not contain the several hours of work that I did between the power outage and “archiving” it by shift-ctrl-s save-as to fn.017.ods

So what I think happened is that after the power outage, and after opening fn.016.ods from my project directory, and after recovering that file, localc started saving files to /tmp/cryoptic-dir-name. I could be wrong about that, but it is the best explanation I can come up with given the facts.

There are two /tmp/cryoptic-dir-name directories. One from yesterday, lu379312329.tmp, and one from today. Yesterday’s has seven files, 5 of which are zero bytes. The file with a time stamp corresponding to what was likely my last 17 save (18:06) is one of the empty files. The non-empty file that corresponds to fn.nnn.ods has the a time stamp (16:14) that predates the power outage, and is exactly the same size (38019) as version 16 in my project directory (which happens to also have the same time stamp, predating the power outage as well).

Multiple ctrl-s saves to fn.016.ods failed

The shift-ctrl-s save-as to create fn.017.ods failed

Multiple ctrl-s saves to fn.017.ods failed

ls -al /tmp/lu379312329.tmp/

total 13276
-rw-r–r-- 1 kj kj 13551154 Feb 6 11:25 lu37931270u.tmp
-rw-r–r-- 1 kj kj 38019 Feb 6 16:14 lu379312guk.tmp
-rw-rw-r-- 1 kj kj 0 Feb 6 09:57 lu3793{23C53A86-4D83-4A82-84C5-5F2180631A85}.tmp
-rw-rw-r-- 1 kj kj 0 Feb 6 18:06 lu3793{606C264B-B160-46F6-A6DC-614FFBF092EA}.tmp
-rw-rw-r-- 1 kj kj 0 Feb 6 15:10 lu3793{6537199A-0231-4228-B6AC-E949DCDFE4CB}.tmp
-rw-rw-r-- 1 kj kj 0 Feb 6 16:52 lu3793{96D3E65C-9C79-4083-A6BC-D5428E3B63D7}.tmp
-rw-rw-r-- 1 kj kj 0 Feb 6 10:29 lu3793{E6550474-CE05-4067-BF4F-1981813C6D54}.tmp

#2

I did a quick repeat of the steps I noted above, including unplugging the computer, but failed to reproduce the same results. Not sure why. Maybe because I didn’t have the ods open long enough to do its once-every-10-minutes backup.
.
At the moment, the /tmp/ul directories no longer exist, nor are there any new ones. File > Recent Documents still lists version 17, and thinks it is here /tmp/lu379312329/fn.017.ods. Yesterday that directory existed, but the file did not exist. Today the directory does not exist either.

#3

Since my first quick-repeat attempt, I have not tried a second time to repeat the sequence that caused the problem. Not fond of unplugging a running system. But will at some point.
.
Before it scrolls off the bottom of the Recent Documents list. I took some snapshots to document proof of the bug: that Calc was trying to save my file in /tmp/lu30294k85sx.tmp/

.
xx1
.
.
xx2

#4

When LibreOffice recovers a file, it is from the tmp directory, which is where the recovery files are created. To save a recovered file, you need to Save As in your regular directory. Best with a different name than the original file in case the original is in better condition.
.
If you save a file to the tmp directory it could get deleted at any time by normal OS file management operations.
.
In the event of the operating system suddenly closing/crashing it is possible that the recovery file was being written to at that time in which case it might not be complete

1 Like
#5

Then /tmp/lu30294k85sx.tmp/ should have contained both the recovered file fn.016.ods (due to multiple saves) and the next version fn.017.ods created via a save-as, and subsequent multiple saves.
.
I doubt the OS singled out fn.016.ods and fn.017.ods. for deletion and left the other files shown in the directory listing in the top post.
.
So either LO deleted 16 and 17 or LO failed to actually save them.
.
For thoroughness, I checked with
.
find / -iname "*lu*tmp"
.
and the only matches are in LO’s
.
/tmp/lu.......tmp/ directories
.
and in
.
~/.config/libreoffice/4/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/
.
These later are timestamped 2026-01-24.

#6

They are definitely deleted. It happens as soon as Calc is exited. Calc recovers files from previous session tmp’s, but saves go into the current session tmp. And that current session tmp gets deleted in its entirety when Calc is cleanly exited.

#7

That’s right. It’s only if LibreOffice crashes out that that the temporary files are left behind.

#8

which means that
launch calc, recover file, ctrl-s save, exit calc
would result in the recovered file being deleted. Given that, when the user launches calc again, they’ve permanently lost what was recovered. Kind of. Since Calc will not offer on its own to recover it a second time, there would need to be a way to induce Calc to do the recovery process again, assuming Calc also hasn’t deleted the tmp from the initial recovery, which it will do based on some schedule unknown to me.

#9

Calc deletes it’s temporary files on successful shutdown.

AFAIK it offers to save the recovered file in the original location. If, because of OS crash, the path to the original file isn’t recorded, I guess the only place it will offer is the current folder. This could be regarded as an unlikely but possible occurrence.

Because having to deal with a recovered file happens infrequently, I take care when saving and always with a different filename.

#10

I can only talk about my current setup, 25.8.4.2 linux, and the situation this morning when Calc froze and I killed the process. I did a few investigations as the situation evolved.
.

On successful shutdown Calc only deletes it’s current session directory and temp files there in. By session directory I mean the brand new directory that Calc creates when launched.
.
An example session directory is `/tmp/lu13705t9pgk.tmp/.

.

Calc’a files in that session directory have one of two naming patterns. Some are like
lu13705{A9DAEF44-17D0-45FA-8727-911BB7AE964B}.tmp.
Those are empty.The other naming pattern is like
lu13705t9pgm.tmp.
Those are not empty.

.

The session directory and the files will have various timestamps, but all the timestamps will be after the time that Calc was launched.
.
All that stuff gets deleted on a normal shut down.
.
If Calc crashes, none of that gets deleted. Future Calc sessions leave it alone for a while, until it decides at some point to delete it. For example Since my crash this morning, I’ve launched and shutdown Calc a few times. Those clean-shutdown session directories and all their content get deleted every time. However the one that does remain is the one from the session that crashed.
.

I can only explain how thing evolved this morning on my system. Calc didn’t actually offer to save it anywhere. But when I actively went to save it, Calc was going to save it in the new temp directory it had just created unless I specified elsewhere. To be clear, it was not going to save it where it found it (old session directory remaining from the crash), nor to the directory where I had been saving it during the crash.
.
So regarding my original post, all my saves and save-as were going in that new temporary session directory, which it promptly deleted as part of its normal shutdown.
.

Depends. It’s happened to me twice within a month.

#11

Regarding LO’s schedule for cleaning up crash-orphaned temp directories …

It’s been about 26 hours and the Calc-crash orphaned temp directory is still there. Calc has not deleted it yet.

.
2026-02-13 08:56 /tmp/lu13705t9pgk.tmp

du -sh /tmp/lu*
97M     /tmp/lu13705t9pgk.tmp
0       /tmp/lu492422cx7su.tmp
#12

LO has no such schedule.

#13

@raindog308 Aug 28, 2025

> Debian 13 “Trixie” [(released August 9th, 2025)] 
> introduces an important change to /tmp.  
> Traditionally, it’s been just another filesystem
> <snip>
> In Trixie, it’s been moved off the disk into memory
> <snip>
> file access is extremely fast.
> <snip>
> [/tmp is] also extremely temporary…
> <snip> 
> Alas, when the server was rebooted…
> <snip>
> you shouldn’t be storing anything there.

> The second mitigating factor is that /tmp is now 
> automatically cleaned up.  Quoting the release notes:
> 
>     The new default behavior is for files in /tmp to be 
>     automatically deleted after 10 days from the time 
>     they were last used (as well as after a reboot). 

> Fortunately, opting out of the new tmpfs world 
> is easy if you don’t like it:
> 
>      systemctl mask tmp.mount
> 
> and reboot.
#14

So … if you’re on a debian box and get fed up with another Calc crash and decide to hit the pub, recovery won’t be an option when you sober up, other than the 12 step genre.

#15

xx
xx800×600 347 KB

https://crashreport.libreoffice.org/stats/

#16

Out of approximately 200 million users, see LibreOffice - Wikipedia

I do know from this site that there are users who deliberately rely on auto recovery when they shut down their computer without first closing LibreOffice. They might account for some of the regular troughs in the graph

#17

Calc crashed again, this time in a different manner. Calc crashed, a Calc popup window appeared, then another popup, then Calc restarted on its own. I didn’t track what was happening in Calc’s temp directory(s). It may have re-used the temp directory from the crashes session, or it may have deleted that directory and created a new one, or something else. I’ve studied all the docs on LO’s temp filesystem and couldn’t tell you. Anyway, when I went to save the file, I saw Calc had pulled a fast one yet again, defaulting to saves going into its tmp directory.

So three (at least) crashes within a few weeks. Power outage. Calc full-crash. Calc crash into recovery.

#18

This is a meta question: why LO crashes so often🤔

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.