Re: imapd and synchronous writes

John Gardiner Myers (jgm+@cmu.edu)
Thu, 14 Mar 1996 12:40:37 -0500 (EST)


sct@dcs.ed.ac.uk writes:
> You really can't just blindly assume synchronous directory updates.
> Even on systems using ffs, where directories are updated synchronously
> (currently), it is not a wise assumption, for things may change in the
> future.

What other option do we application developers have? Until Linux came
along, directory updates had always been committed before the call
returned. There are no facilities provided to applications to let
them specify that a directory update needs to be committed to disk.

"Sorry, you're just screwed" is not an acceptable answer.

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:
> I seems that we'll need something like "opendir(..., O_SYNC)", or at

Does that help rename(), link(), unlink(), symlink() calls? Those
calls don't supply the DIR returned by opendir()

> least a new mount option to default to synchronous directory (only)
> writes.

Doesn't help applications. Do you really expect sysadmins to create a
separate partition, mounted synchronously, for their mail spool?

"Theodore Ts'o" <tytso@MIT.EDU> writes:
> Actually, there is, but it's not portable. If you open the directory
> using open, and then call fsync on the resulting file descriptor, you
> will forcibly commit the directory change. This is *not* guaranteed to
> work on all POSIX systems, and indeed it may not work on many. But it
> will work under Linux.

How is an application, written to compile on a broad range of unix
systems, to know it has to take this particular set of steps?

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up