Put the backup file in a separate folder

• Sep 21, 2016 - 23:24
S5 - Suggestion

The hidden backup files automatically generated when saving are a significant irritant for me, often causing confusion (I can't count the number of times I've attempted to open one of them by mistake instead of the real file).

Please don't tell me to turn off hidden files. I exercise complete control over my system, so of course I have it set to show hidden files, and these things are a significant annoyance. As it is, I spend a lot of time deleting them so they don't cause confusion, thus losing the safety net they are meant to provide. But it's worth it to preserve my workflow.

Surely a good compromise would be to place these hidden backups in a separate folder which the user can control from Preferences | General | Folders.


The backup files are a byproduct of the safe write procedure MuseScore is using:
- write into a temporary file
- rename the original file into the backup file which removes the old backup file
- rename the temporary file into the original file name
MuseScore omits the last step of deleting the backup file as i believe its very useful.

Moving the backup files into separate folders is a bad idea as it makes the whole process
less robust:
- there can be name conflicts
- if the folder is on a different filesystem (disk) then moving (renaming) is not possible, only copying which
can fail for various reasons

You don't want to hear it but the right way is to not show hidden files. For complete control i guess there
is an option in your filebrowser to show all files.

OK, then please allow the user to turn off this function altogether. I'm sure it helps some people, but I save my work often enough that it's not worth the bother for me. I lose a bit of work from a crash every once in a while, but it's very much worth the price.

And no, it is not an option to hide files. Showing them is the only way to have full control over one's system and keep it completely clean.

In reply to by [DELETED] 3

i can see you need the atomic action (rename) to avoid interruption on saving. But that is only upon saving..
There is no specific reason not to use a separate directory where all temp files reside, and upon saving ename the file there and supsequently move the file to the desired directory. Agreed, there is an interruption sesitive moment between rename and the move, and during the move if the temp directory is not on the same filesystem, but the file is always retrievable.

Pseudo-code for the actual workflow: (based on Telegram discussion)

// Pseudo-code for fix #125656
// Version 1 by Howard C.
bool haveBackupFile = /* there is/are score(s) like .(originalName)-(int).mscz, */
std::vector<backupScore*> allRelevantBackupFiles = /* all scores having the name of .originalName-(int).mscz, */
if (!haveBackupFile) {
else {
      int a = -1;
      size_t b = allRelevantBackupFiles.size();
      for (score : allRelevantBackupFiles) {
            if (score->findMetaTag(originalScorePath)) {
                  a = intOfBackupScore(score);
      if (a == -1) {
      else {

So, this was discussed with the developers and we determined to have an alternative solution. Will be done later. As for this, I don't want to mark as "won't fix" too soon, but it's of high possibility.

the discussed solution of using a hidden '.backup' folder in the score's folder for those backup files is not an entirely different idea, so still covered by this issue, "Put the backup file in a separate folder", it just won't be an arbitrary configurable folder.

In reply to by Jojo-Schmitz

Agree with Jojo, there is no reason to parametrize that folder.
Using always the same name being a subfolder of the place where you save the score will help to find backup and will solve the two questions around that change:
-no name conflict
-keep atomicity of move rename as move on the same disk is just a rename in file system. The move and rename will be a unique atomic action as desired.

Thanks to the developers for first allowing us to turn this off if desired, and second to have a different folder. Great news on both counts.

Fix version