DragonFly users List (threaded) for 2008-01
DragonFly BSD
DragonFly users List (threaded) for 2008-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: renaming the current working directory (cwd)

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Sat, 12 Jan 2008 03:51:38 +0000

Vincent wrote:

If my cwd gets renamed by another process, it disappears out from under

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'.

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.



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]