All expected behavior.
Make a folder, let us say "xyz" on desktop and cd to this location on a terminal using 'cd' command.
Now rename that folder to "abc".
Now type 'ls' command on Terminal to see the content of folder "xyz", it still shows.
The 'cd' command makes a chdir() system service call, which opens the target directory and stores the open file descriptor in the process.
When you rename the folder, that just changes the directory entry in its parent folder, it does not change the file system inode for the directory nor does it affect already open file descriptors to the directory.
So when you do an 'ls' with no path, the 'ls' command will ask the file system for the '.' (current directory), which the file systems knows to use the current working directory it already has saved in the process.
This is how Unix has worked forever.
In addition if you use 'pwd' command, it still shows that you are in directory "xyz"
'cd' and 'pwd' are
bash built-in commands, so
bash has cached the last 'cd' path, and when you issue 'pwd',
bash just echos the cached path information. It does not verify anything before displaying the path.
If you want to see the real current path, then try using
/bin/pwd
this will do the more complex reverse path reconstruction, which can have some unexpected responses, because of symbolic and hard links that may have been used to navigate down to the current directory location.
Worse is that even if you delete the folder "xyz" and empty trash. Even then using 'pwd' command would show your present working directory as "xyz" folder.
Again,
bash is just echoing the cached path that
bash last knew about.
Also since the process still has an open file descriptor to the directory open in the process as the current working directory, the file system will defer the actual directory delete until after that file descriptor is closed.
The fact that a file or directory will not be truely deleted if it is still open, allows an application to continue to use a file if it has it open, even when some other process deletes the file. This can be good for the application, but if that was a huge file and you were trying to free up space, you would not see the space returned until after the process that has the file open, closes the file.
You can use the 'lsof' command to find what processes have what files/directories open.
In the future, if you have additional Unix or Terminal related questions it would be best to post them in the Mac OS X Technologies > Unix Forum
<http://discussions.apple.com/forum.jspa?forumID=735>
