Adam, First - my hands are up: I suspect you may be right that my fs may be the culprit (at least partially). The picture library was on an XFS drive and it's true that delayed allocation could cause data loss. It would require the process to crash or be interrupted before a sync has occurred though. I'm going to do some more rigorous testing but would love your comment on my current train of thought.
I have had Shotwell crash on me (mostly previous releases), though I don't recall it doing so on this occasion. Moreover, if I understand correctly, the delayed write/allocate wouldn't actually be the problem in itself. Rather, files have to be open for write and bsomething has to happen to prevent the sync. Or put another way XFS may simply serve to amplify an underlying issue? The sub-set of files that were corrupted corresponds, I think, to the files that were edited in some way. Does (can) tagging alone cause the image files to be opened for write in 0.9.2? Or are there other features that can result in writing to image files in bulk? Stepping back I decided to check whether there are any other apparently corrupt (zero length) files on my drives. note: this system has been running with moderate with XFS on my home partition for a couple of years. There were a few - one more small group of photos and a few seemingly related to the only other app that I use that has a bulk editing feature: Banshee. Again the files go in groups. Coincidence I wonder? I'm pleased I have good backups! Could I be barking up the wrong tree? How many files in theory could Shotwell have open for write at any one time? Delayed write is likely to be a feature of all new filesystems (ext4 and btrfs are good examples.) Perhaps there are some implications for developers of file processing apps? Antony On 2 May 2011 21:17, "Adam Dingle" <[email protected]> wrote: _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
