MuseScore fails on Save with error "Result too large"

• May 16, 2018 - 15:15

MuseScore 2.2.1 on Windows 10
OS: Windows , Arch.: x86_64, MuseScore version (32-bit): 2.2.1, revision: 51b8386

I made multiple changes to a small score (28 measures), but when I tried to Save the score MuseScore reported an eror with the Temp file "Result too large".

I have Autosave enabled (2 minute interval), and I had worked on the score for about 10 minutes before trying to save explicitly. What might I be doing to have triggered this error message?

Comments

Shoichi

• May 16, 2018 - 15:19

Could you attach here your score?
Try to give it a new name (short)...

Jojo-Schmitz

• May 16, 2018 - 15:22

Not sure, but the filename looks quite long?
Doesn't look like longer than 260 characters though, which seems to be the limit in Windows?

mike320

• May 16, 2018 - 15:41

@Jojo, can you look in the code and see what triggers that error?

Jojo-Schmitz

• May 16, 2018 - 15:59

      //
      // step 1
      // save into temporary file to prevent partially overwriting
      // the original file in case of "disc full"
      //
 
      QString tempName = info.filePath() + QString(".temp");
      QFile temp(tempName);
      if (!temp.open(QIODevice::WriteOnly)) {
            MScore::lastError = tr("Open Temp File\n%1\nfailed: %2").arg(tempName, strerror(errno));
            return false;
            }

strerror(errno) maps the errno number set by the prev QFile::open(OpenMode) to an error string. "Disk full" should give ENOSPACE though which in turn should give "No space left on device", here we seem to get ERANGE, for reasons I don't understand.
If the filename were too long, I'd expect a different error

DanielR

• May 16, 2018 - 16:41

@Jojo My laptop has 494Gb still free, so it isn't a disk space problem. And the folder structure (which does have multiple sub-folders} is excatly the same as I have been using for several months. After posting the original message I made the changes to the score a second time, being careful to Save and close the file after each bunch of changes. I didn't shorten the filename or make any changes to the folders - and the score saved perfectly every time. Is it possible that MuseScore was trying to buffer too many unsaved changes on the first attempt to Save?

Attached is the score as it was before I started work and received the error.

Attachment	Size
Schumann_Robert_Liederkreis_Op.39_No.1_In_der_Fremde_I.mscz	42.59 KB

Jojo-Schmitz

• May 16, 2018 - 16:47

Unlikely, that QFile::open() shoud be agnostic to the undo stack in MuseScore.
I'm at a complete loss of an explanation

Shoichi

• May 16, 2018 - 16:51

I don't think it's related but the score you attach was generated with 2.1 and the original format is music xml?
Here it can also be saved without any problems by also ' lengthening ' the name.

Attachment	Size
Schumann_Robert_Liederkreis_Op.39_No.1_In_der_Fremde_IBis.mscz	38.85 KB

Jojo-Schmitz

• May 17, 2018 - 16:26

Funny, today I had the same problem. I then just deleted the score file (while still having it open in MuseScore) and then saved it successfully

mike320

• May 17, 2018 - 16:30

Was your score also imported from xml?

Jojo-Schmitz

• May 17, 2018 - 16:33

No, created myself from scratch, a mere 10 measures one instrument, from the treble clef template, my sample score for https://musescore.org/en/node/272465

frfancha

• May 28, 2018 - 10:40

Same problem for me today with a very small new score

Marc Sabatella

• May 28, 2018 - 16:57

What is your "Z:" drive? That's an odd-looking pathname, my guess is the Z drive is a temporary drive that is not connected properly.

mike320

• May 28, 2018 - 21:37

I've seen the Z: drive used to indicate things like online storage, now called "The cloud" or something like that. I want know why a .mscz.temp file is being saved.

jeetee

• May 28, 2018 - 21:51

It's an attempt to not loose your data.
We first save into a .temp file, then once done rename it to the real file (renaming a file is much faster than writing it)

Also see the comment in code explicitly mentioning this reason: https://github.com/musescore/MuseScore/blob/49068ccf6f25c71679f90935a94…

mike320

• May 28, 2018 - 22:24

I didn't notice DanierR having the .temp on the original post and Jojo didn't mention it. I guess showing the name with the .temp suffix allows a programmer to see exactly which step failed.

frfancha

• May 29, 2018 - 11:27

The Z: drive is the net use of my NAS. I have used Z: because it was free on all PCs present at home and easy to remember by the family that they always have to save/work on the Z: to avoid losing work in case of laptop crashing and to be able to access it from any laptop and avoid fighting between children because "he has the laptop with my school homework!".

Jojo-Schmitz

• May 29, 2018 - 11:31

And this shouldn't be relevant, I had the issue with a fine in C:\Users\Jojo\Desktop and of course my C: drive is not full nor am I lacking access privileges to my own Desktop folder

But see also the very old issues #3032: Compatibility with 0.9.4 and #3047: reading file ............ failed: Result too large, there it happened on reading rather than writing, and only if the path to the file contained a diacrit. I don't see this here though.