dataloss: mcedit save of existing file on full sshfs file system causes empty file

[baryluk]

I don't how this happened, I am using 3:4.8.25-1 from Debian testing.

Never happened to me before in last 15 years.

I had sshfs filesystem mounted, and for external reasons (a background deamon) it got full.

I was editing a file, about 200 lines of code. I tried to save, and it failed. I exited, and reopened file again. It was empty. Few hours of work lost.

This is a critical flaw. There was no backup file, no atomic rename for save either.

Maybe it was something to do with mount options, I don't know.
sshfs -o cache_timeout=360 -o cache_stat_timeout=360 -o entry_timeout=240 -o negative_timeout=200 -o kernel_cache -o workaround=none -o cache_max_size=100000000 -o reconnect

But, mcedit recognized the error it can't save, so while the original data disappeared?

[andrew_b]

Closed as duplicate of #2470.

[zaytsev]

So if it failed to save and you were notified of it, what do you expect mcedit to do if you just exit afterwards and confirm that you will loose unsaved changes?

I understand that it's always frustrating to lose hours of work, but what you should have done instead is to investigate why it's telling you it can't save the file and e.g. saved the file as another file on another partition or just copy & pasted things out to rescue the data, especially if it's just 200 lines of code...

[baryluk]

Replying to zaytsev:

So if it failed to save and you were notified of it, what do you expect mcedit to do if you just exit afterwards and confirm that you will loose unsaved changes?

I understand that it's always frustrating to lose hours of work, but what you should have done instead is to investigate why it's telling you it can't save the file and e.g. saved the file as another file on another partition or just copy & pasted things out to rescue the data, especially if it's just 200 lines of code...

Let me be a bit more specific, what happened:

• I opened a file in mcedit
• I modified a SINGLE line. Easy, quick, not significant.
• Tried to save using F2 (or maybe F10 actually).
• It failed, and shows some error message.
• I assumed it just failed to save the change.
• I did exit the mcedit, to investigate what is going on.
• I opened the file again. It was empty.

The data loss was not just the one line I added, but whole progress during the day.

This is a problem.

I use mcedit, because it starts up very fast, and works fast, so I enter and exit it hundredths of times per day to terminal and back to mcedit.

Sure, if I would be a bit more careful, it would not happen, but everybody sometimes ignores weird messages, especially if they happen only once per decade. I noticed it failed to save, but I assumed, it just failed to save a new version, and previous one is there.

It wasn't.

mcedit should follow a safe approach, as other editors often do, of saving in auxilary file, then doing atomic rename (possibly with fsync/fdatasync before doing the rename). Or moving the old file to the .bak file, or something like this, and then writing the content of the file.

[zaytsev]

Hi baryluk,

Thank you for a more detailed explanation!

I was assumming, that you are using "Safe save" mode (unlike the poster in the linked ticket), and just ignored the message about mc's inability to save the file, but apparently you are not. mc can already do what you want in the "Safe save" mode - it creates a new file and renames it to the old name - only in "Quick save" mode (default) it does a truncate instead. It also has a save mode in which a backup file is created. Switch to those modes, and you won't experience such problems. Quick save is then only used on mc internal VFS files, because there is no way to tell, whether they support renames.

Andrew, should we not just make "Safe save" a default for now? Do you see any reason why we shouldn't? The speed difference nowadays should be insignificant for file sizes that mcedit is able to handle. It can fail more often for nearly full file systems, because it needs twice the file size, but arguably now that megabytes are a commodity, this wouldn't matter as well, and better to fail this way as truncate and then fail to save? People seem to be getting tripped up quite regularly, because they just don't know that there are different save modes and how they work, and I don't quite see why would they necessarily need to live this pain.

I wonder what ossi as the creator of #15 would say...

Yury

[ossi]

i would go a bit further: i don't think "quick save" as a configuration option even makes sense - it's not significantly quicker at all. instead, it should be seen as a workaround that is applied selectively after confirming with the user that they want to take the risk.

the workaround is required in at least these cases:

• the file has hard links, and the user chooses to not detach
• the file is owned by someone else, and the user wishes to retain that ownership, while not being root themselves
• the VFS does not support copying the file's extended attributes (hmm, does mc even support that at all? if not, that would be a reason for defaulting to quick save)
• the user has no write permission to the parent directory, or the VFS doesn't even support renames
• the medium runs out of space, as unlikely as that is nowadays with files that are suitable for a text editor

to address the OP's immediate concern, which would remain valid even if the above and/or #15 were implemented:

• under no circumstances should 'cancel' in the error dialog leave the editor, or should the modified state be reset - hopefully that's already the case
• choosing to exit without saving should pop up a separate confirmation dialog mentioning that the original file has been possibly destroyed
• that 'destroyed' state should be remembered for subsequent attempts to exit without saving