From: utzoo!decvax!ittvax!swatt Newsgroups: net.bugs.v7 Title: Re: Bug in link() Article-I.D.: ittvax.412 Posted: Thu Aug 12 10:17:08 1982 Received: Sat Aug 14 06:12:27 1982 References: mi-cec.133 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