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