Rick Troth writes:
> Malcolm Beattie said:
> > ln foo foo.bak
> ...
> > cp foo newfoo
> ...
> > mv newfoo foo
> > Atomically replaces the directory entry foo: before the
> > command (specifically: before the system call "rename" that
> > mv does for you), opening "foo" refers to the old file; after
> > it, opening "foo" refers to the new file. At no time is there
> > a window where no file named "foo" exists and at no time is
> > there a window where both exist or get mixed up in any way.
>
> And furthermore DOES NOT HARM "foo.bak", correct?
Correct.
> I think this is why I have never used the above sequence
> of atomic operations: I did not trust it to leave "foo.bak" intact.
> But you could help set my soul at rest about this matter.
Absolutely. foo.bak is a link to a completely different file--let's
call it "inode 1234" just to be more concrete and to separate out
the idea of "filename" from "underlying file"/"inode". (Even if
you're using some modern filesystem that doesn't think of itself as
really using inodes, it's got to pretend it does from the point of
view of these operations.) Then you start with a directory entry
"foo -> 1234", do a "ln foo foo.bak" which adds an entry
"foo.bak -> 1234" and then do "mv newfoo foo" which atomically
replaces the "foo -> 1234" entry with "foo -> 5678" (whereas before
there had been "newfoo -> 5678"). If you follow all the links, it
all works out nicely.
The guaranteed semantics of rename(2) are documented in SuSv2 at
http://www.opengroup.org/onlinepubs/007908799/xsh/rename.html
One thing to note is that the Linux man page I have documents that
there is allowed to be a window in which both "newfoo" and "foo"
both refer to the same file (the file being renamed, i.e. the one
with inode 5678 in the above example). I'm not quite sure how one
could observe such an event (does it imply getdents(2) is allowed to
return both the "newfoo -> 5678" entry and the "foo -> 5678" entry
in the returned buffer of a single call?) since there is no way of
issuing both opens "at the same time" in any observable way.
Nevertheless, this "both newfoo and foo may exist at the same time"
part of the semantics does not affect the issue that you were asking
about: nothing with this renamed entry can affect the contents of
inode 1234. Note, of course, that any process which had inode 1234
open (the old "foo") before the rename can continue to access/modify
it if it wishes. If you access "foo.bak" (which refers to the same
inode) then you are accessing the very same file and your accesses or
modification will be seen by those processes that opened it under its
other name (the old "foo") and vice versa.
>
> And if it is true on Linux, is it also true on HP, Sol, AIX, ad nauseum?
Yes.
> This forum is devoted to Linux, but we all continue to need to consider
> other flavors of UNIX for maximum portability. We just need to know.
--Malcolm
--
Malcolm Beattie <[EMAIL PROTECTED]>
Linux Technical Consultant
IBM EMEA Enterprise Server Group...
...from home, speaking only for myself
