I can't open my file. What is the cause?

• Dec 13, 2017 - 14:57

I have a theory as to why people are getting files that cannot be opened and are filled with blank space rather than their scores.

I believe this has something to do with auto save kicking in at the same time that the user is saving their file. Many users say that they work on the file for a very long time, pressing the save button often to prevent loss of data only to have their file corrupted. My problem is that I have no idea how to test the theory. Does anyone have an idea of how to test it? Perhaps a developer could put MuseScore into debug mode and force a user save and auto save at the same time on a test file to see if the file becomes corrupted. If I were to do this I would try it with the auto save kicking in then press the save button as well as press the save button immediately before auto save kicks in. The best I can tell, most of the corrupt files reported are larger files, so there would be a relatively long time (to a computer) required to save the files.

I work on a lot of large files, and I turn off auto save because it freezes my computer while it's saving. I instead save my file often and have never experienced one of these corrupt files.


Comments

I think the same thing for a long time.
But I couldn't create a test environment to prove the theory.
This problem happened several times on the Polyphone. (Polyphone is also compiled with QT.)/ /(But, Polyphone doesn't have AutoSave feature.)
But when I looked carefully, I saw it; this problem doesn't occur during normal "save" (Ctrl+S); but occur when you want to quit the software. (When the "Do you want to save it?" question is answered) //in Polyphone.

Based on this, I assume that the problem is:
(It's just an theory.)

There are changes in the file that have not yet been saved.
The user wants to exit the software.
The software opens a query window. "Do you want to save it?"
The user clicks on the "Yes" button, while the "AutoSave"'s time's up and running
And something goes wrong.

PS: I keep the AutoSave feature turned off all the time. And I never got a bad ".mscz" file on my PC.

I too would love to understand how this happens, but I am skeptical about the autosave theory. Autosave files are stored in a totally separate file and shouldn't cause any conflicts with the regular save operation. The result save works by first saving a temp file to the same folder as the actual file (not the backup, this is totally different) - same name as actual file but with ".temp" appended), and then only after the operation completes, the actual file is deleted and the temp file is renamed to the original name. This should be bulletproof, but somehow it seems to randomly fail. My best guess is that it is the writing of the temp file that is failing, not the final act of replacing the main file with the temp.

I guess what does seem remotely possible is that if an autosave kicks in while the temp file is being written, there are two files being written at once, and somehow an internal buffer (perhaps deep within Qt) is being clobbered. I'd expect this to result in garbage, though, not a bunch of zeros. Anyhow, if this is the guess, once should be able to reproduce the problem with some effort by creating a large score that takes at least a couple of seconds to write, making a change, waiting one second less than the autosave interval, hitting save, and hoping for the worst :-). Might have to repeat this many times to create a problem as it could be that even if the autosave triggers the issue, it only does occasionally due to some race condition within Qt.

If nothing else, it probably wouldn't hurt to disable the auto save timer during the regular operation. Could maybe even just force an autosave right before the regular save, then reset the timer.

Do you still have an unanswered question? Please log in first to post your question.