Re: renaming the current working directory (cwd)

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Vincent Stemen wrote:
> On 2008-01-12, Bill Hacker <wbh@conducive.org> wrote:
> > Vincent wrote:
> > > Hi.
> > >
> > > If my cwd gets renamed by another process, it disappears out from under
> > > me.
> > >
> > > To reproduce:
> > >
> > > $ mkdir zzz1
> > > $ cd zzz1
> > >
> > > In another shell:
> > >
> > > $ mv zzz1 zzz2
> > >
> > > Back in the first shell:
> > >
> > > $ ls
> > > ls: .: No such file or directory
> > > $ cd ..
> > > cd: no such file or directory: ..
> > >
> > >
> > > This seems to be unique to Dragonfly.  I tested on FreeBSD, NetBSD, and
> > > Linux and, it does not affect the shell that was in the directory
> > > because it was never deleted.  I verified, in Dragonfly, that the inode
> > > number of the directory did not change after being renamed.
> > >
> > > Is this a bug or a feature?
> > >
> > > I am running DragonflyBSD 1.10.1-RELEASE
> > A misunderstanding, perhaps...
> >
> > On FreeBSD, OS X or OpenBSD the more common action is an rm -Rf - which 
> > results in the original shell looking at a no-longer-valid dirtree, and 
> > saying so when you try to do an ls ... or whatever. 'no such file or 
> > directory'.
> >
> > My test was to add to your test - above - 'touch fudge' while in the 
> > dirtree, then rm -Rf the dirtree from a different shell and try to ls or 
> > 'touch fudge2' from the shell still in the now-removed dirtree.
> >
> > As expected 'no such file or directory' was returned.
> >
> > Likewise trying to backstep with 'cd ..' as the point of reference is 
> > lost. Needs a specific cd /path/to/whatever/still-exists
> >
> > Then I tried an 'mv' with the 'fudge' file in place...
> >
> > OS X 10.3.9, OpenBSd 4.2, FreeBSD 6.2 are the same as DFLY.
> >
> > The original shell still shows in prompt that it is in the OLD dirtree 
> > and still sees the file 'fudge'.
>
> Yes, this is what I expected to get and what I do get on every other
> system.  My FreeBSD test was also on version 6.2.  But it behaves as if
> the directory was removed on Dragonfly.  Are you sure you tested on
> Dragonfly as well?

No - I specifically did NOT test on Dragonfly... (as you had already 
done so). I just happened to have all three of the others running at the 
time. I *can* add another HDD and check DFLY, but trust you are not 
inventing this...

;-)

> If so, what version?  I also tested today on our
> other Dragonfly machine running Dragonfly 1.8.0-RELEASE and got the same
> results.  The directory disappears on the original shell.  

As above it, *should* disappear *unless* the change used hardlinks.

> I did another test today.  I renamed the directory back to the original
> name in the second shell and it reappeared in the original shell.
> Unlike the other Unix systems, the shell on Dragonfly seems to require
> the name to stay the same, not just the inode.  I also verified it was
> not a characteristic of the specific shell.  I got the same behavior in
> Zshell as well as sh.
>
>
> shell1 $ mkdir zzz
> shell1 $ cd zzz
> shell1 $ touch fudge
> shell1 $ ll
> total 0
> -rw-r--r--  1 vince  vince  - 0 Jan 12 13:18 fudge
>
> shell2 $ mv zzz zzz2
>
> shell1 $ ll
> ls: .: No such file or directory
>
> shell2 $ mv zzz2 zzz
>
> shell1 $ ll
> total 0
> -rw-r--r--  1 vince  vince  - 0 Jan 12 13:18 fudge

Again - trusting your tests - that 'hints' to me that Dragonfly has not 
used (the classical) hardlink approach - wherein the information is not 
destroyed until the 'last known' consumer of it has relinquished it.

I could be wrong about that - plus - I'm not sure I would class it as a 
'bug' even if true.

Note that to the best of my recollection, DOS, Win, OS/2, and many other 
non-Unix OS'en would also be no longer able to find the path or file 
once 'rename' 'ed OR deleted by another's action.

OTOH - depending on which fs was in use, several of those would have 
prevented the second shell from doing so in the first place because 
another 'consumer' had it 'open'. Ergo, the behaviour can be fs-specific 
as well as OS-specific.

> > Any other shell does not. It sees them in the new dirtree. NB: This OS X 
> > is using UFS, not hfs
> >
> > What I believe you are seeing is neither bug nor 'feature' - just a 
> > normal characteristic of hardlinks, which mv will use when possible.
> >
> > Your shell that sits 'IN' the mv'ed dirtree has it 'open'. Once you move 
> > off of it, howver, that link is eaten and you cannot go back.
> >
> > HTH,
> >
> >
> > Bill

And therein may lie the key.

First impression is that an OS/fs combination should *either* 'track' 
the change made by others - or prevent such chasnges.

Yet 'rm' and 'mv' already behave differently on Unix and FFS/UFS.

Which one is 'right' depends on whether the goal is consistency with 
other *nix or consistency between 'rm' and 'mv'.

Personally, I am au fait with DragonFly doing it a different way than 
other *nix - so long as that is the intent and 'fits' the rest of the 
model. DragonFly tends to be both very well planned, and to tkae 
cognizance that a good deal of 'legacy land' has long been in need of 
cleanup.

One would expect that an *unplanned* change from 'legacy' could break a 
whole host of other things expected by convention - but there is scant 
evidence that it has done so to-date.

I'll cite an unrelated example of 'differences':

 - On FreeBSD one can open several shells, do a pkg_add in each of them 
and watch them run simultaneously. Likewise a 'make'.

 - On OpenBSD, the second and subsequent commands are told that the 
pkg_db is already open & locked. Each is then held until the first 
finishes, then run one-at-a-time until all are done.

The OpenBSD approach may take more wall-clock time to complete. But it 
is arguably less likely to get tangled in its own underwear (dirtrees, 
libs and other dependencies & their versions).

AND/OPR needs simpler code to prevent that.

AND/OR - FreeBSD needs more complex code to handle that sort of activity 
w/o harm.

So long as neither one breaks, I'm agnostic as to how they accomplish that.

If all 4 *BSD's were identical, 3 would be superfluous ...

;-)