Why does the pwd doesn't update after directory removal?

Question

I tried a little experiment where I created 2 folders Dir1 and Dir2 inside my Desktop directory, such that Dir1 is parent of Dir2. /home/username/Desktop/Dir1/Dir2

Then, I use cd to set my pwd as /home/username/Desktop/Dir1/Dir2. Next I used rm -r /home/username/Desktop/Dir1 to remove the Dir1. Now if I use pwd it still shows it to be /home/username/Desktop/Dir1/Dir2, which now doesn't exist. Also at this time if I use ls or cd .. it generates an error saying 'Cannot access /home/username/Desktop/Dir1/Dir2: No such file or diectory', which is ablsolutely true but I was thinking this issue generated because of pwd not getting updating after folder deletion.

The solution to this is also simple as far as I can think, you can go the parent directory and then delete the requested directory.

I want to know if there is some specific reason for pwd not getting updated, is my solution is correct and/or I just found a bug ?

Answer 1

Actually, Dir2 does exist, but the name Dir2 does not. Confused? :) The shell's current directory is still the directory referred by the name Dir2, and this keeps the directory still around. This is analogous to anonymous files. Normally, when a files link count goes to zero, the file is deleted and the inode freed. However, if a process still has the file open, the kernel does not delete the file until the process closes the file, either explicitly or implicitly by exiting. In Dir2's case, the shell is still having the directory "open" as long as it doesn't change its current directory.

What is gone are the names Dir1 in the Desktop catalog and the whole hierarchy of names below it, including the . and .. entries. The directory formerly known as Dir1 is also gone (assuming no other process has it as current directory). Files and directories at the inode level do not form a hierarchy, i.e. there are no links from inodes to parent, child or sibling entries. The hierarchy is built up separately by directory entries, which are essentially (name, inode) pairs, pointing to files and other directories.

After this lengthy introduction we can rephrase your original question so that it reads: "why does the shell not change its current directory to something else, when the directory entry Dir2 is removed from Dir1?" Well, one reason is that the shell doesn't even know this. Some other process has run the rm program and removed the directories, but there is no mechanism by which the shell would be told about this. Second, which directory would the shell choose as its new current directory? The directory is changed using the chdir system call, which takes a string containing the new directory as argument. The shell could try a chdir(".."), but as we saw above, we already destroyed the .. entry! Third, why should the shell change the current directory? It has no reason to do so, it is comfortable where it sits, and it is not in the habit of magically change directories without being explicitly told to do so.

Granted, the situation is kind of pathological, but it is up to the user to avoid it.