On Fri, Nov 28, 2003 at 12:28:25 +0100,
Marco Colombo <marco@esi.it> wrote:
>
> My understanding of the problem is: UNIX fsync(), historically,
> used to sync also directory data (filename entries) before returning.
> MTAs used to call rename()/fsync() or link()/unlink()/fsync()
> sequences to "commit" a message to disk. In Linux, fsync() is
> documented _not_ to sync directory data, "just" file data and metadata
> (inode). While the UNIX behaviour turned out to be very useful,
> personally I don't think Linux fsync() is broken/buggy. A file in
> UNIX is just that, data blocks and inode. Syncing directory data
> was just a (useful) side-effect of one implementation. In Linux,
> an explicit fsync() on the directory itself is needed (and in each
> path component if you changed one of them too), if you want to
> commit changes to disk. Doing that is just as safe as on any filesystem,
> even on ext2 with async writes enabled (it doesn't mean "ignore fsync()"
> after all!).
A new function name should have been used to go along with the new semantics.