Follow-up Comment #5, bug #19465 (project mypaint):
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.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?19465>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Mypaint-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/mypaint-bugs
