phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (02/16/91)
I discovered the following when trying to use "mv" to rename a directory in order to syncronize a shell script so that only one could operate on a set of files at one time under circumstances where more than one instance might get started at once occaisionally. The shell script runs in the background and today I had a situation where a couple of them got started in parallel. When two (or more) "mv" commands try to rename the same file OR DIRECTORY to two DIFFERENT names at the same time, the result can be two separate hard links to the same inode. In the case of directories, "ln" (or the underlying system call) will refuse to allow this to happen except if the uid is root. While the non-atomic nature of "mv" might cause some syncronizing problems with shell scripts that assume it is atomic, the fact that this can happen to directories appears to be a more serious problem. Has this been reported anywhere yet? -- --Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society <phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.
jim@cs.strath.ac.uk (Jim Reid) (02/20/91)
In article <1991Feb16.000101.4149@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes:
When two (or more) "mv" commands try to rename the same file OR DIRECTORY
to two DIFFERENT names at the same time, the result can be two separate
hard links to the same inode. In the case of directories, "ln" (or the
underlying system call) will refuse to allow this to happen except if the
uid is root.
This is not unreasonable on a multi-processor with a re-entrant
kernel. On a uniprocessor, the rename() system call is "atomic"
because no other process can be executing kernel code (and renaming
the same files) at the same time. In DYNIX, it is possible for several
processes to be executing rename() at the same time on different
processors. Although hardware locks are used to synchronise access to
the inodes as their link counts are changed, this will not prevent the
behaviour you describe from happening.
Jimcsg@pyramid.pyramid.com (Carl S. Gutekunst) (02/20/91)
If you are talking about DYNIX (4.2BSD), this is not true; the rename(2) system call is used and it is atomic. Assuming you aren't using the mv(1) in the att universe, of course. If you are talking about DYNIX/ptx (SVR3.2), then you are correct. There is no rename(2) call, mv(1) is not atomic (it uses link(2) and unlink(2)), and you are SOL. That's just the way System V works. [Editorial Comment: Companies that give the same name (or a trivial variation, like the version code) to radically different operating systems should be lynched by their justifiably outraged customers. That includes the old Gould, which had who-knows-how-many different things all called UTX; Sun, which last I knew is going to call their SVR4 port "SunOS 5.0"; and many others. Sequent chose to walk a very well trodden path, and I know of other companies that plan to follow.] <csg>
petebob@sequent.UUCP (Pete_Bob Apple) (02/21/91)
In article <145463@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >If you are talking about DYNIX (4.2BSD), this is not true; the rename(2) >system call is used and it is atomic. Assuming you aren't using the mv(1) in >the att universe, of course. The att universe version of mv_dir uses the rename(2) system call. The ucb universe is just as described, the standard 4.2BSD version of mv(1). >If you are talking about DYNIX/ptx (SVR3.2), then you are correct. There is >no rename(2) call, mv(1) is not atomic (it uses link(2) and unlink(2)), and >you are SOL. That's just the way System V works. That's not how DYNIX/ptx works. There is a rename(2) system call in DYNIX/ptx and mv(1) has been changed to use it. rename(2) has been there from the beginning of DYNIX/ptx. I believe mv(1) was changed to use rename(2) for the V1.1 release. [Editorial Comment: Remember, I'm a just an en-g-neer, not a spokesman:] One of the ideas behind calling the new operating system DYNIX/ptx was to give the impression that it is based on the original DYNIX. Many important features from DYNIX (such as rename(2)) were added to DYNIX/ptx while still maintaining industry standards. (SVR3.2, SVID, POSIX, XPG, etc) Personally, I wanted to call it DYNIX_Bob, but no one listened to me. :-) :-) -- Pete_Bob Apple Sequent Computer Systems petebob@sequent.com, sequent!petebob 15450 S.W. Koll Parkway Bob is not just a name.. Beaverton, Oregon 97006 It's a way of life.. (503) 626-5700
rbj@uunet.UU.NET (Root Boy Jim) (02/21/91)
In article <53625@sequent.UUCP> petebob@eng3.UUCP (Pete Apple) writes: ?In article <145463@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: ?>If you are talking about DYNIX (4.2BSD), this is not true; the rename(2) ?>system call is used and it is atomic. Assuming you aren't using the mv(1) in ?>the att universe, of course. ? ?The att universe version of mv_dir uses the rename(2) system call. It took AT&T long enuf to realize they needed mkdir, rmdir, and rename system calls. Unfortunately, they still insist on this nonsense mvdir command. ?The ucb universe is just as described, the standard 4.2BSD version of mv(1). Except that the standard isn't 4.2 anymore. It's 4.3. And beyond. There are many of your customers who are distressed at the low baud rate at which bits flow from UCB to each of your companies. ?>If you are talking about DYNIX/ptx (SVR3.2), then you are correct. There is ?>no rename(2) call, mv(1) is not atomic (it uses link(2) and unlink(2)), and ?>you are SOL. That's just the way System V works. Ooooh, that's scary! However, I wonder about the AT&T broken ln syndrome. Somewhere along the line, AT&T broke ln(1) so that if you do: who > a; ls > b; ln a b you will get one file with two links successfully, rather than two different files and failure. ?That's not how DYNIX/ptx works. There is a rename(2) system call in ?DYNIX/ptx and mv(1) has been changed to use it. rename(2) has been ?there from the beginning of DYNIX/ptx. I believe mv(1) was changed to ?use rename(2) for the V1.1 release. Well, Carl, that'll teach you to post flames in a hostile newsgroup :-) ?[Editorial Comment: Remember, I'm a just an en-g-neer, not a spokesman:] ?One of the ideas behind calling the new operating system DYNIX/ptx was ?to give the impression that it is based on the original DYNIX. Many ?important features from DYNIX (such as rename(2)) were added to ?DYNIX/ptx while still maintaining industry standards. (SVR3.2, SVID, ?POSIX, XPG, etc) And SVR3.2 isn't the standard either. SVR4 is. And don't forget the most important standard: BSD. I hope that PTX will not include this dual universe nonsense. A unified approach (such as the one taken by Sun and Dec, probably others) is much better. Users want the best features from both systems. ?Personally, I wanted to call it DYNIX_Bob, but no one listened to me. :-) :-) ?-- ?Pete_Bob Apple Sequent Computer Systems ?petebob@sequent.com, sequent!petebob 15450 S.W. Koll Parkway ?Bob is not just a name.. Beaverton, Oregon 97006 ?It's a way of life.. (503) 626-5700 I think you're too close to Twin Peaks :-) -- [rbj@uunet 1] stty sane unknown mode: sane