"Save As" silently fails for some filenames

• Jun 18, 2021 - 10:52
Reported version
3.6
Type
Ergonomical (UX)
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
duplicate
Regression
No
Workaround
Yes
Project
MuseScore
  1. Open a musescore file
  2. Save it as (for instance) "Example 2.1-1" (set "Example 2.1-1" in the name, click "save")
  3. Nothing is saved, no error is shown.

The file should be saved as Example 2.1-1 OR (equally correct) Example 2.1-1 suffixed with the musescore extension corresponding to the "save as" format.

Comments

• Jun 18, 2021 - 10:57
Status active ⇒ needs info

Regression vs. what previous version?
What version exactly?
What Operating System?

And no it should never ever save without the proper extension. There's a Linux distribution notoriously know to do that, workaround is to use thw Advanced preferences tonight use the native file dialog

Reply

• Jun 18, 2021 - 11:33

Hi.

I use the flatpak version (currently 3.6.2) on debian

Not sure it's a proper "regression" : The stable debian version (2.3.2) cuts part of the filename (after the dot?), but at least, something is saved !

Note that the native file dialog is activated (tonight!) in the flatpak version (I did not set that myself).

"And no it should never ever save without the proper extension". Well, relying on windows-like file extensions is not perfect either, no opinion on that. "Example 2.1-1.mscz" would be fine to me, as "Example 2.1-1" would be fine to me.

Reply

• Jun 18, 2021 - 12:01

Well, the issue is not at all about the way the file extension question is handled in musescore. As I said, I have no opinion on that.

The issue i did report is that, in this version, clicking "save" closes the "save as" box, does NOT save the file, and does NOT warn the user that nothing is saved.

Reply

• Jun 19, 2021 - 17:09
Status active ⇒ needs info

To be clear - extensions are not Windows-like, they are native to Linux as well.

My guess is the file was saved without the extension, but because it has no extension, it doesn't show later in the "open" dialog, because it is not recognized as a MuseScore file. That's perfectly ordinary behavior of pretty much any program on any OS if you save a file with no (or an incorrect) extension.

If you can verify that no file at all is saved on your system (on mine it certainly is), can you post screenshots and/or video demonstrating this?

Reply

• Jun 19, 2021 - 21:29

I'm also using the Flatpak version of Musescore (3.6.2) on Debian-based MX Linux as the second operating system and I haven't had this kind of problem so far.
If you add one of the problematic files (which cannot be saved with the save as command), I can test it. // I assume that you have normally-saved at least one of the files that caused this problem before.

Reply

• Jun 20, 2021 - 09:22

Hi

In case you read the issue a little to fast, I gave the precise steps to reproduce the bug (first message of the issue report) as well a description of the bug (same message and issue title), and the musescore version (third message).

If you're interested in documenting/reproducing the issue, just follow the precise steps I listed, which I think are sufficient.

Now if following exactly these steps with the same version does either create a file or trigger an error message, I can investigate a little more for you.

Reply

• Jun 20, 2021 - 17:41

When I was using your example, I had habitually added ".mscz" to the end, so it was fine.
see: attached screenshot

About to the problem that occurs when saving a previously unsaved file with the "save as" command:
The problem is caused by using the dot character(s). The character after the last dot is assumed to be the file extension. In fact, if there are two dots in the file name, depending on the situation: part of the file name can be considered as directory, file name and suffix.

You can actually generate this error (not silently, but with a warning window) in the featherpad text editor. Open a new file, give the command "save as" and type test2.1-1.1 as the filename. An error message will appear immediately.

from the errorlog:

(featherpad:7916): Gtk-CRITICAL **: 18:02:46,731: gtk_file_chooser_default_set_current_name: assertion 'impl->action == GTK_FILE_CHOOSER_ACTION_SAVE || impl->action == GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER' failed

 
And yes the QTdialog (or whatever dialog system is being used) must somehow understand the return of the system error message and pass it on to the user (like featherpad does). But it is also possible that this problem is disappearing between System => QT <=> Flatpak.

Workaround: Try not to use dot characters in the filename. If you do, make sure to include the file extension (".mscz"). // Note: If you have opened a previously saved file, the file extension is already attached and visible. when you try to save it with the "save as" command. Put the new filename before the ".mscz" suffix.

Attachment Size
Screenshot_2021-06-20_17-55-05.png 177.23 KB

Reply

• Jun 20, 2021 - 21:53

@Ziya Mete Demircan Thanks for taking the time to reproduce the bug !

In the current version of MuseScore/src/userscores/internal/filescorecontroller.cpp

The following methods

void FileScoreController::saveScore()
void FileScoreController::saveScoreAs()
void FileScoreController::saveScoreCopy()
void FileScoreController::saveSelection()

all contain these copy-pasted lines :

if (selectedFilePath.empty()) {
return;
}

followed by :

doSaveScore(...)

So if I understand correctly these lines and if they have not been changed since the flatpak release I used, it seems the explanation of the issue is that the error path is simply ignored (treated as if the "cancel" button of the save dialog had been pressed) when an error message should be shown.

Reply

• Jun 22, 2021 - 18:42

Musescore must have a filter in its source code so that the software can know the file-type it can save at that time and show the previously saved ones in that save/save-as window.
If all the save/save as/save copy code is this much, it must be calling another function.

Also:

 If (selectedFilePath.empty()) {
 return;
 }

There must be an "errorlevel" detection followed by a redirection to a function (there is probably a function that evaluates the error-codes returned from the system).

Unfortunately, I didn't pay much attention to the source code of this software, except for a couple of places linked in the forum before. At the moment, I can only think about what should or shouldn't be there for me and write my predictions about it.

Beyond that, it's up to the software developers.

Reply