On Fri, 2009-03-13 at 22:16 +0100, Alexander Larsson wrote: > Its well explained in the various discussions about this. Essentially, > the metadata for the rename is written to disk, but the data in the file > is not (yet, due to delayed allocation) and then the system crashes. On > fsck we discover the file is broken (no data) and set the file size to > 0.
This reminds me a lot of http://bugzilla.gnome.org/show_bug.cgi?id=562396 - a problem with Nautilus metadata. You start a copy operation, but if you do a read before the copy is done, then you get the "old" data. You should wait for the copy to be done first, but anyway, my point is... My point is that the kernel could perfectly well ensure that metadata operations that depend on data operations will not be reordered. "Don't rename a file in a directory if we have outstanding writes for the inode", or something. (After the rename, do you need to open the directory and fsync it? You can't open directories for writing...) Federico _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
