> To avoid this, Postfix *must* do fsync() or fdatasync() after the
> write() and before the fchmod()+fsync(); that will insure that the
> execute bit implies valid ("committed") data in the file. I was
> unable to find any such call to fsync() or fdatasync(), but as I
> mentioned, I am probably simply misreading the code.
Thanks for clarifying, I'm asking Wietse to figure if Postfix's
queue file format is sufficient to check integrity.
> > It looks so to me. After the MTA behaviour has been dug up, the
> > dirsync option could be even weaker if fsync() behaved like FFS +
> > softupdates: sync the directory entries, including those of link and
> > rename, as well.
>
> Ideally, this would be an option you could set per-application (as
> opposed to per-directory or per-mountpoint), because we are really
> talking about allowing Linux to support applications written for BSD
> file system semantics. It is not obvious to me what the best
> implementation for that would be, though. Maybe just a compile-time
> option to choose the appropriate open/link/rename/etc. operations.
To add to that confusion and alternatvies:
HAVE: async, sync
SUGGEST: 1. BSD dirsync, 2. "weak" unlink/symlink dirsync and have
fsync() track and sync pending link/rename as well, 3. make just symlink
dirsync, 4. be confused of all the options.
Where this could be set: directory inode flag, mount option, process
flag (like umask), include file.
Seriously, if fsync() syncs the effects of link and rename as well,
there's no need to make them synchronous unconditionally except if one
wants to offer a "traditional BSD synchronous directory semantics" mode.
-- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/