Urgent Support Needed for File Corruption Issues - Students Losing Years of Work

• Nov 7, 2024 - 10:10

Good morning. We are experiencing urgent issues with MuseScore at our school, where many students’ files are randomly getting corrupted and turning into 0KB files. This has particularly been happening more with ones saved within file shares.

We have ensured that all computers are running the most up-to-date version of MuseScore, as we saw on forums that older versions could be problematic. Despite this, the issue persists, and more files are being corrupted. For instance, one student saved a new piece of work, and within five minutes, the file became corrupted when they tried to open it again.

We have managed to restore some students’ work through hidden files, but this has not been successful for all cases. We have checked the AppData, backup folders on local computers, and ensured that our school antivirus software is not causing the issue.

We urgently need support to determine if this is an ongoing bug and any assistance on how to prevent this from happening and recover the corrupted work.

Thank you for your prompt attention to this matter.


Comments

This seems to be a problem more associated with saving to the cloud. I would suggest also saving to the student's hard drive. And/or doing something like that suggested by yonah_ag above.

In reply to by patelm2

Everybody wants this fixed as soon as possible, believe me. :) We are still working on it, it takes some time for something like this to go through the established procedures. :). But let me shed some light as to what to expect.
In the next version, 4.5.0, MuseScore Studio will be checking the saved file after each save to see if it is healthy or not. In case it is corrupted, MuseScore studio will show a dialog with a couple of options: Try again (simply retry the save) and Save As... (to try and save the file to a different location). Offering a "Try again" option on the dialog will allow the users to retry the save and let us know if retrying the save fixes the issue or not (always, never, sometimes - we don't rule out anything for now since we have not been able to reproduce the issue ourselves). It might be a somewhat random issue so we believe simply retrying the save could succeed the second time (or the third or fourth, etc.). The Save as... option will be there to tell us if the problem is related to where the files are getting saved. While we don't know yet what these two options will reveal, there is another result of this change: the users will know right away that their files have been corrupted, as soon as it happens, and if none of the options on the dialog help to save successfully and continue working, at least the users should have a healthy backup at that very moment. There's a bit more to it, but I'll keep it for later. :)
Since 4.5.0 has not been released yet, what we are doing right now is we are implementing this same coprruption check for 4.4.3 and will release it as soon as it has passed all the testing and approvals. I hope it is a matter of a few days.

In reply to by krasko78

Hi Krasko,

I apologise for the delayed response.

We are still experiencing the issue despite updating to version 4.4.3. Could you please provide any updates on when the corruption testing will be conducted with 4.4.3 or the expected release date for version 4.5.0?

We are eager to support you in resolving this issue and are willing to trial any new updates or fixes you have. We are very keen on working together to get to the bottom of this problem.

Thank you for your assistance.

In reply to by patelm2

Hi patelm2,

Just when I was thinking of giving you a new update, here you are asking for one. :) What I said previously was completed soon after I wrote you, but things changed a bit in the meantime. The initial idea was to release a 4.4.3 version with only the corruption check I mentioned (that's why it was going to be a matter of days), but then the team decided to make a 4.4.4 release with more fixes included. This is the reason for the delay. So let's wait patiently for 4.4.4. Unfortunately I don't know the exact release date, not even a tentative one.

In reply to by krasko78

Whilst we wait for version 4.4.4 and the fix for identifying corrupt downloads (which seems like a step in the right direction) could we ask what URLs the downloads are served from. As this problem seems extremely intermittent I wondered if the issue could be with some peoples firewalls and blocks happening here. If they are all from a small subset of URLs we can allow these via an exception and see if that mitigates the issue.

In reply to by patelm2

Good to hear that the MuseScore Studio team are getting involved.

Just in case it helps, this is my personal file versioning scheme when I develop scores:

Scores Folder Structure

FV01.png

• Scores in development start life in the Dev folder.
• When I reach a significant point a copy gets saved to the Milestone folder and uploaded online as private.
• Scores ready for release are saved to the Published folder and uploaded online as public.

Score Versioning - a recent example

FV02.png

The corresponding uploads can be seen in the score's version history on musescore.com:

FV03.png

Usage Notes

Maybe this scheme is a bit too granular for your use but it can be easily adapted. It gives plenty of recovery/rollback options. As you can see, (no versions before 0.8), I delete some of the older Dev files periodically. I typically make a new Dev version after a session of editing, (which may have had some simple File > Saves as well because I don't use automatic saves).

I have made it more manageable via a plugin:

FV04.png

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