On Tue, 19 Feb 2013 17:00:32 +1100, Nikolas Kallis <n...@nikolaskallis.com> wrote:
> Hello, > > > > I have found a bug in Bash: > > /opt/foobar$ > /opt/foobar$ rmdir ../foobar/ > /opt/foobar$ > > With the above, one can see I deleted the directory 'foobar/' from > within the directory itself. What one can also see is that after I > deleted the directory, I was still in it according to Bash. > > This is a bug because Bash is telling me something which is not true. > > To fix this, Bash needs poll to confirm the file system location its > working in still exists, and to to move to the next valid '../' when the > address it was working in no longer exists. > > Perhaps this can be done automaticly, automaticly only if there is no > input, or on the next return. > On the next return would be safest I think. Bash has nothing to do with this, it's an operating system level behavior. If a process has a file open (ie, a file descriptor referring to that file) and the file is deleted, the process can still use the file until it closes it. However, the file ceases to be externally visible from the moment it's removed, to stop other processes from using it. When you're in /opt/foobar, bash has an open file descriptor referring to the directory. If you (or anyone) deletes the directory, it's no longer visible from the outside, but as long as there is at least a file descriptor referring to it (which there is), the operating system keeps it available to the processes using it. So really, to bash (and any process that have it open, if there are others) the directory still exists. /opt/foobar$ lsof | grep foobar bash 10990 waldner cwd DIR 254,0 4096 17638570 /opt/foobar /opt/foobar$ rmdir ../foobar /opt/foobar$ lsof | grep foobar bash 10990 waldner cwd DIR 254,0 0 17638570 /opt/foobar (deleted) /opt/foobar$ cd .. /opt/foobar$ lsof | grep foobar /opt/foobar$ -- D.
