bugMyPaint - Bugs: bug #19465, Catastrophic file loss can occur...

Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #19465: Catastrophic file loss can occur on power-loss

Submitted by:  Máirín Duffy <mairin>
Submitted on:  Sat Feb 18 03:35:34 2012  
Severity: 3 - NormalPriority: 5 - Normal
Status: FixedPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: mypaint-1.0.0-2.fc16.x86_64Planned Release: None
Operating System: Fedora 16

(Jump to the original submission Jump to the original submission)

Sun Jun 22 16:19:28 2014, comment #6:

This should be fixed in git master as of https://gitorious.org/mypaint/mypaint/commit/6d8d00e6721e81b6bb179d48e40bb881de5d47b7

MyPaint now makes backup files (.BAK) when saving over or exporting on top of an existing file, and tries to balance filesystem safety across Linux/ext4 and Windows.

Andrew Chadwick <achadwick>
Project Administrator
Mon Apr 16 11:53:37 2012, comment #5:

UNIX-philosophically, I don't like the idea of fsync()ing each and every file when written. After all, our application is /not/ the most important app on a system... we shouldn't be spinning up the disk like that if we don't have to. In use cases like Máirín's it's could even help provoke an earlier system crash.

One option is renaming existing files with the same name to a backup file instead of deleting it. Vi-style "foo.ora~" would be a reasonable choice, since it's a widely known convention to file managers and other desktop software. That way users have one more chance of finding an old, hopefully properly synced, copy. Of course it's only /one/ more chance, and if /neither/ copy is synced before the renames happen, the "atomic" writes still won't be truly atomic. Meh, filesystems.

Second option is to just get off the Unixy high horse and fsync() if os.fsync exists before closing and renaming. Just to be sure. After all, our userbase consists mostly of artists, not sandal-wearing UNIX mystics. There should always be one synced copy on the disk, and this approach is at least robust. Potentially fork() the part that does the sync and the renames to avoid slow disk spinups making the app less responsive.

I think we need to pick one and go with it. Making it a user toggle would be unhelpful, since most users won't care about tradeoffs between security and battery life.

Andrew Chadwick <achadwick>
Project Administrator
Sun Feb 19 07:31:36 2012, comment #4:

Could a missing fsync() call have caused this problem? See http://mjg59.livejournal.com/108257.html (although note I'm using ext4)

After I powered the laptop back up, the file was in the directory I originally saved it under with a filesize of 0 bytes, and attempts to open it up in MyPaint and Gimp failed (they said unable to open file)

No .tmpsave file anywhere. There were two mypaint directories in /tmp but both were empty. (tmp2RwLkBmypaint, tmpNqOEb1mypaint were the directory names) It's definitely not in the ~/MyPaint directory either.

Máirín Duffy <mairin>
Sun Feb 19 06:18:45 2012, comment #3:

Well, some excerpts of save_ora() in lib/document.py:

It saves into the same directory, not into /tmp, because /tmp might be on a different filesystem, and then the rename would be expensive. And this is very old code.

Maybe you can tell us a bit what actually happened? Did the file disappear after you rebooted, or was it empty, or did you get an error when you tried to open it? Can you unzip it? Does it contain the same layers? Did you find a '.tmpsave' file? Did load a file into the scratchpad maybe? What have you tried to analyze the problem - e.g. have you checked if the file was maybe saved to ~/MyPaint/ instead?

Martin Renold <martinxyz>
Project Administrator
Sat Feb 18 20:17:56 2012, comment #2:

It was definitely ORA format. And it did not save to tmp, it saved to the pre-existing file in my homedir. How could this have happened?

Máirín Duffy <mairin>
Sat Feb 18 07:20:52 2012, comment #1:

We already do that, at least for ORA. What file format did you save?

Martin Renold <martinxyz>
Project Administrator
Sat Feb 18 03:35:34 2012, original submission:


My machine was almost out of battery. I pressed save to save my work. The battery cut out before the file was fully saved. I lost all of my work. All 2 hours of it. If I hadn't pressed save I would have lost 5 minutes worth of work.

It would be better, if you are performing a save operation, to save to a /tmp file, and then move that file over the existing file only when the new version has saved fully.

This could have been avoided this way, I think.

Máirín Duffy <mairin>


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by jonnor (Updated the item)
  • -unavailable- added by achadwick (Posted a comment)
  • -unavailable- added by martinxyz (Posted a comment)
  • -unavailable- added by mairin (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Jun 22 16:19:28 2014achadwickStatusConfirmed=>Fixed
    Sat Jan 5 12:50:01 2013jonnorStatusNeed Info=>Confirmed
      SummaryCatastrophic file loss=>Catastrophic file loss can occur on power-loss
    Sun Feb 19 06:18:45 2012martinxyzStatusNone=>Need Info
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup