Bug in link()

[utzoo!decvax!ittvax!swatt]

I've just checked our 4.1bsd sources; they have made the same fix.
Note that it is NOT namei which sets u.u_error, but suser.  This is
quite reasonable and it does set it to EPERM.  I've also just checked
an old listing of V7 sources (existed on disk on Jan 10, 1979).  Their
strategy was a bit different and didn't have this error.  Do you
happen to know the geneology of your sources?

It appears the change was intended to eliminate a race condition
involving someone unlinking a directory just as someone else was
linking to it.  The old code had to unlock the inode for the first
directory before calling namei on the second (if the second had a path
through the first, the namei would hang). The new code first updates
the first directory inode with the new link count, unlocks the inode,
and then calls namei on the second name.  Thus if someone else comes
along and unlinks the first name, the inode is not flushed because its
link count is still non-zero.  This of course requires a later
decrementing of the inode in case some error prevents the successful
link operation.

	- Alan S. Watt
	[decvax!]ittvax!swatt