retext icon indicating copy to clipboard operation
retext copied to clipboard

Autosave can result in lost of the entire content of a file

Open adessein opened this issue 6 years ago • 7 comments

Hi,

I have just experienced a loss of data on two files. FILE1 was an old file opened but I was not working on it. FILE2 was a new file that I was modifing when my computer crashed (not due to Retext).

When I restarted my computer both files were empty. What is frustrating is that FILE1 has been saved at some point, it is not like I have never saved. FILE2 has actually just been opened, not modified at all, still, his content vanished.

I had autosave enabled.

I think what happened is that retext has automatically saved the files with an empty content (for some reason...).

I think you should reconsider the autosave feature. It is dangerous to save on the original file without the user's consent. And I can see that some people are confused by the fact that the save button is disabled. It should behave like an auto-backup, a feature often seen in other programs. It should save the changes into a temporary file until the user actually saves the file. Then the temporary file is deleted. If the computer crashes and the program restarts, the existence of the temporary file is detected and the user is given the choice to open the backup instead.

adessein avatar May 29 '19 19:05 adessein

I am sorry that you had data loss because of ReText.

ReText writes files in order, not simultaneously. So when your computer crashed, at least one of the files should have been saved on disk. Maybe this is a filesystem issue? If it had not been unmounted properly, then data loss could occur. And in this case backup copies would not help…

I have just pushed a commit that makes files auto-saved only when they are modified. This should avoid re-saving of opened but not modified files.

I am not opposed to the idea of backup copies, I just don't see how they would have helped in your particular case.

mitya57 avatar May 31 '19 16:05 mitya57

Hi mitya57,

Thank you for you quick reaction to my issue. What happened is a bit weird and I am not sure I explained well. Just to make sure you understand, I will rephrase.

I had two instances of ReText opened, two different files. I was only editing one of them. After I restarted my computer after it froze, both files were empty. As if ReText had autosaved with just nothing. And it did on both files, even the one that was not modified.

Therefore I think your commit could help for the non-modified file. However, the root cause is still hard to understamd: why did ReText saved an empty file over the existing ones?

Maybe you are right, it is not ReText, it is the filesystem. It is hard to say.

adessein avatar May 31 '19 18:05 adessein

To know the root cause, I need some way to reproduce it.

I tried killing ReText process when auto-save is enabled, in all cases the file was saved correctly (not having last-minute changes, but not empty).

mitya57 avatar Jun 01 '19 04:06 mitya57

edit After looking at the code better, the described behavior in the bug is to be expected with the current code. Modern filesystems can take many seconds before they actually write data to disk, due to performance reasons. You won't see this by killing ReText, you'll need to crash/hard reset the system to see this happen. Applications are supposed to call fsync if they want data to be written to disk immediately.

ReText should do savestream.flush(); os.fsync(savefile.handle()) before closing the savefile. (Maybe QT has a native way to do that but I didn't find that.)

That still leaves a small interval between clearing the old content and writing the new content. What many editors do is save the file content in a temporary file (and fsync that), which can be deleted after the original file has been successfully written to and fsynced. On startup, the editor can check if any such temporary files exist, if that is the case it offers the user to open it so the user can save again if wanted.

JanKanis avatar Jul 13 '19 21:07 JanKanis

I would agree that having autosave saving backups would be valuable. Something like filename.backup.pid ... using the process ID in case multiple instances of retext are open (possibly even on multiple hosts with dropbox or similar shared folders). I would rather remove left over backups and clean up after a crash than risk data loss. This would go hand in hand with https://github.com/retext-project/retext/issues/517 to allow editing on multiple systems.

internationils avatar Jun 15 '20 06:06 internationils

I just found half of a file gone - my guess is this happened like this:

  1. inadvertantly select half the file and press a key
  2. autosave triggers
  3. close the app without realizing the above

Probably I should turn off auto-save to avoid this?

But I'd like to see some kind of rolling backup algorithm that saves the last X versions of a file (maybe on application startup?)

djowett avatar Jan 03 '23 12:01 djowett

Strangely I found the file recovered today, which is a great relief! I'm not sure why though, perhaps it was only half displayed yesterday for some reason :shrug:

Rolling backup would still be nice to not feel 1 step away from disaster

djowett avatar Jan 04 '23 21:01 djowett