Make saving an atomic operation
Saving the score should be an atomic operation so that – no matter what happens – the use is always left with a file containing a valid score. In the worst case the state of that score will be the one from the last successful saving operation.
There are two issues (#63271: Changing instrument names may lead to crash and empty mscz file and #87021: Crash on saving results in complete data loss (Version: 2.0.2, Linux)) reporting crashes that result in an empty score, among others when saving the score. Assuming that the empty scores result from the application crashing DURING the writing of the file these issues would be highly mitigated by making saving an atomic operation. Also, finding the cause of the crashes (which are hard to reproduce) would become much easier since the user can start reproducing the crash from a much more recent state.
Comments
FWIW - normally, in the event of crash while writing, you should still have the auto-save version left over from no more than two minutes ago, so no significant loss of data would occur. It's really these occasional zero-length files that occur *not* in conjunction with a crash that seem the bigger issues, since if there is no crash, and you close MuseScore, the auto-save file would be deleted. And unfortunately, the change suggested here would very possibly have no effect on that issue.
Ok, I see...I'm a littel confused with the different backups MuseScore does because there also are the .<score_name>.mscz, files lying around but apparently these are not the auto-save files. Anyway, I'll close this since it does not seem to fulfil the intended purpose. I guess my solution will be to keep Dropbox running the whole time so I can go back in history ;-)
While the feature might not really help a lot in these situations for these reasons, it's not without value, so I would just as soon see the request stay open.
I guess the thing some programs do is write a new file with a temporary name, and then only after the file is successfully written and closed is the original file removed and the new file renamed to the original. This can have issues with file created / modified dates not being what people expect, and it might confuse the versioning in programs like Dropbox, but anyhow, again, to me it's worth keeping this possibility in mind.
This may be a minority position, but I vastly prefer the manual saving system. The ability to, if I choose, close the score and not save changes is something I value.
Oh, of course. Nothing suggested here changes that. Auto-save never saves your actual score, nor should it ever, nor has anyone suggested otherwise. The suggestion is just about the technical details of how "manual saving" is implemented, to make it less likely to yield a corrupted score in the event of a crash.
A simple partial solution to the basic issue (crash during save can result in zero-length score) occurs to me: we could simply make a backup copy of the score as a prelude to each save operation, then clean it up afterwards if the save succeeds. We could even consider using the existing backup for this purpose - I'm not sure people really love have tht backup date back to when the score was last opened as opposed to last saved. But there should be no problem keeping both - ".Score.mscz," as is, maybe ".Score.temp.mscz," for the temporary version.
To me this sounds like a very good safty mechanism!
we could simply make a backup copy of the score as a prelude to each save operation, then clean it up afterwards if the save succeeds.
I might miss something but it's more or less how saving a score works currently. https://github.com/musescore/MuseScore/blob/master/libmscore/scorefile…
1/ Save the file to a temporary file filename.mscz.temp
2/ Remove the backup file .filename.mscz, if it exists
3/ Move the existing filename.mscz to .filename.mscz,
4/ Move the temporary file (filename.mscz.temp) to filename.mscz
the backup date back to when the score was last opened
If we are talking about .filename.mscz, it's clearly a bug... To me this file is created only when the file is saved, not when the file is opened.
One last point, "auto-save" is definitely a bad name. We should rename it to "Automatic Background backup" or "Automatic Session Backup" or something along these lines.
That's interesting. I was observing two different behaviors on crashes (see #87021: Crash on saving results in complete data loss (Version: 2.0.2, Linux) #10), one that left a <filename>.mscz.temp file behind and one that didn't. Two thoughts:
(1) Maybe the zero-length score in #87021: Crash on saving results in complete data loss (Version: 2.0.2, Linux) is not produced by a crash during writing the file but instead a zero-length score is the intended outcome (in the sense of no crash happening at that stage), which is as usual written to the <filename>.mscz.temp file and then moved to the <filename>.mscz file. A crash after writing <filename>.mscz.temp would explain the first case while a crash after moving to <filename>.mscz would explain the original behavior.
(2) For me, too, the .<filename>.mscz, file remains untouched throughout many file saving operations (Linux, Version 2.0.2). If this is a bug, as it seems, fixing it would solve the "atomic saving operation" issue in my view.
Sorry, I meant to say the backup dates to when the file was "first saved during the current session" not "last opened" . The point being, we don't update the backup on each save; we only do so it the first time the file is saved in any given session. The comment here makes that explicit:
https://github.com/musescore/MuseScore/blob/master/libmscore/scorefile…
That's the way it has always been, and I think most people find it surprising, so I'd be perfectly happy to see that behavior changed.
The code to use the temp file is never hit in the case where where the file has already been saved. That is,
https://github.com/musescore/MuseScore/blob/master/libmscore/scorefile…
does not use any form of temp file.
Maybe this is naive, but it seems to me that simply removing this block of code solves both problems at once: we have more meaningful backups, and we are better proptected against crashes during save.
This is basically "fixed" now in the nightly builds, yes?