File save can't determine file type without extension

• Nov 25, 2019 - 00:43
Reported version
S4 - Minor
PR created

Many programs allow typing the name of a file without a file extension, and then allow a corresponding drop-down box for file-type to dictate the extension to the operating system without forcing the user to explicitly type the .extension. Musescore, however, won't save a new file without typing in the extension.

I.e., if the user types "my_file" without an extension, even though the extension drop-down box says "MuseScore 3 file", it won't save and grant an error-message. This should be fixed, as it is a minor annoyance. It's not major, most definitely, but it should be fixed, and this should apply for any file-type selected in the drop-down list without requiring explicit typing of the user. Same goes for exporting.

Interestingly, this doesn't seem to have been mentioned at all (I think it's easy to disregard the problem and not mention it since it's not a big deal).


Which operating system are you using. It works on Windows 10 as expected when the Use Native Dialogs option is checked. I didn't try it with the option not checked.

In reply to by mike320

Hey, nice point. Linux Mint 19.x here. No customization as to whether or not native dialogues have been changed on it.

Just tried enabling use native dialogues, but afterwards typing in a filename and making sure that no extension was used, the error "Cannot determine file type" still occurs.

In reply to by worldwideweary

By the way, it looks like by default the Linux AppImage has [use native dialogues] disabled, whereas Windows has it by default enabled based on my experience. At any rate, a fresh install on Windows 7 with (default) native dialogues enabled doesn't have this problem, but if it's disabled, it does. And again, even with it enabled, I'm getting the error on Linux.

Frequency Once Few

Also occurs in other dialogs, e.g. File→Export, or File→Save as in the Plugin Creator.
I have been running into this issue on Manjaro for a long time, both in AppImages & when installed from the distro repo.
OS: Manjaro Linux, Arch.: x86_64, MuseScore version (64-bit):, revision: 2ba915f

Try unticking Edit > Preferences > Advanced > ui/Application/useNativeDialogs (this used to be the default for Linix, but is no longer and since quite a while)
If it helps, it is a different issue that repprted here though.

In reply to by Jojo-Schmitz

Workaround No Yes

Thanks for the info. This workaround kinda works.
The built in (non native) dialogue adds the file extension and it saves appropriately.
However If I remove the extension or just type a file name with no extension the file is saved with no extension, and the file system thinks it is a .zip file.
If I go "Save as" with extension it works fine. With no extension I get a "cannot detirmine file type" error reported.
This is Mscore 3.6.2 on LinuxMint 20.1
There is no issue in Mscore 3.0 on Windows 10 NativeDialogs are ticked.
So there is a bug somewhere.

It's perfectly normal that if you explicitly give a filename with no extension, or with the wrong extension, things won't work as expected. That's been true for as long as file extensions have been a thing. The only issue is that some file dialogs don't automatically pre-fill the extension in all cases. Pretty sure it's the Qt file dialog system that decides how to handle this, and for whatever reason, I guess they've decided some Linux users prefer to type the extension themselves.

In reply to by Marc Sabatella

Aside: To exemplify that it isn't quite "perfectly" normal:

LibreOffice easily allows typing a filename without any explicit extension, selecting "PDF"/"ODT" or whatever on export, and the resulting file will be "filename.pdf" after exporting in the user's file system, even though the filename string doesn't have an extension showing during the dialog:

A quick GIMP check also will complain via dialogue if there is no extension given, but then selecting from the drop down "Select File Type (by extension)" will automatically add that extension to the filename string or alter it to fit the selection as a nice user supporting action rather than necessitating the user type it like how it is happening here in Linux for MS if the user erases the supplied filename at the beginning stage of saving. Especially useful if one has a tendency to "clear" the filename string after a CTRL+A or something and type a name without extension:

If MuseScore had the corresponding file extension not be selected, but only the main filename when doing Save As dialogue, I think that would probably help with those who have this issue. Same goes with Export dialogue. Something simple like:
On my system, the whole string is highlighted when Save As or Export is enacted.

I said it's normal "if you explicitly give a filename with no extension" - the ley word being "explicitly". Again, yes, on some systems, some programs may automatically fill this in by default. If you explicitly clear it, it's completely standard expected that you'd get what you explicitly asked for.

The point being, the extension is part of the filename, and even on systems where it gets filled in by default, explicitly clearing or changing it should be expected to work. The only question is, how hard does any particular dialog on any particular OS try to prevent you from doing this. Some make you explicitly choose a file type of "all files" to get a non-default extension, for example.

I'd imagine it'd be nice if the behavior were:

1) If the extension explicitly exists, use it.
2) If not, append the "Files of type: " extension in the dropdown box so that no resultant mscx or mscz file-type is lacking the appropriate extension, or rather as it is currently: no file results because of the ensuing "can't determine filetype" dialogue.

I really think we should reinstate ui/Application/useNativeDialogs being set to false for Linux (and Linux only), basically reverting 3390aab

This topic comes up time and time again, esp. lately

In reply to by Jojo-Schmitz

@Jojo, probably a decent default. Even with that, if there is no extension typed in, this system gives the error:

filetype det.png

Good news is by clicking the drop-down list and selecting, the extension will be emplaced once again if the user typed a filename in earlier without one, so that makes for a pretty decent workaround instead of having to type in the extension if forgetful: