I'm having an interesting problem on a non-NetBSD operating system
(Solaris), but it should apply equally well to NetBSD, since it's the
same FFS behavior as we're used to.  It's about Unix filesystem
semantics.

The problem is this: on certain machines here, we rewrite four
configuration files at boot time using a shell script, by moving aside
the old versions and blatting out new ones with "echo".  Sometimes if
the machines boot uncleanly after this process, the files are found to
have zero length.  I assume what's going on for each file is:

	* The directory entry and inode for the new file are written
	  out as soon as the file is created.

	* The file contents themselves are cached, and don't get
	  written out until some indeterminate time in the future.

So, I have a few questions about safely updating files in shell
scripts:

	* Is there any way to synchronously write out a file in a
	  shell script?  Running "sync" will cause files to get
	  written out sooner, but doesn't let you wait until a
	  particular file has been committed to disk before updating
	  the directory entry.

	* Suppose I write a little program which opens a file,
	  fsync()s it, and then closes it.  Will that be sufficient to
	  synchronously commit all previous writes?

	* With the fancy new soft update thing, directory entries are
	  not written out synchronously when files are created.  Do
	  you have to open and fsync() the directory to make sure the
	  directory entry has been updated?  (Of course, the
	  consequences of a directory entry not being updated are not
	  catastrophic in this case; I'll just get the old version of
	  the file.  But in other cases I might care.)

Thanks.