On Fri, 14 Jun 2002, Greg A. Woods wrote:

# Where'd (or more properly "when did") you get off the boat from?  :-)

Oh, dammit, there's that lapse of memory again.  I forgot, it was mkdir()
that wasn't atomic for a while (under 4.1BSD mkdir() was a
mknod/link/link sequence).  My bad.  You're right, of course.

# rename(), by all definition since forever, not counting stupid wrapper
# functions written (after rename() was first defined) by software porters
# who cared more about building a complete runnable binary than about
# building a correctly runnable binary, is an atomic operation.  A
# rename() is never supposed to leave the filesystem in any state where
# the file is not linked in any directory.  Now of course a crash in this
# case would only be troublesome if there were a bug that caused the
# inode's reference count to go to zero at a time when there were no
# directory entries on-disk for that inode.  If such a bug existed then
# 'fsck -p' would (as currently implemented in NetBSD) silently (almost)
# wipe that file from existance.

Now interestingly enough, I had a whole bunch of files on a filesystem
at work (the same one that caused this whole discussion in the first place)
get reconnected, even though the fsck reported "UNREFERENCED FILE I=..."
just like the other time (last time it said (CLEARED), this time it said
(RECONNECTED)).

[interestingly enough, it reconnected a lot of things -- enough that it
took me making three separate lost+found directories to store them in.]

				--*greywolf;
--
NetBSD: Networking Space