renaming the current working directory (cwd)

[Vincent Stemen]

On 2008-01-12, Bill Hacker <wbh at 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?  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.  

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



> 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