bug-coreutils
[Top][All Lists]
Advanced

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

Re: Is this bug in "rm"?


From: Bob Proulx
Subject: Re: Is this bug in "rm"?
Date: Wed, 2 Jan 2008 18:32:58 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

Oto Brglez wrote:
> # mkdir /var/folder; cd /var/folder
> # rm -rf ../folder/
> # pwd

Files (and directories which are simply special files) are reference
counted.  Effectively the filesystem garbage-collects when the
reference count is reduced to zero.

Because your current working directory was keeping the directory busy
it was not actually deleted.  The reference count was not zero.
Therefore the program still had a directory that existed.

The rm command did unlink it from the directory above it however.  The
directory no longer has a parent.  The ".." entry has been removed.
If you were to do a list of all of the files there you would no longer
find a "." or ".." entry.

This is rather like climing out on a limb of a tree and using a saw to
cut off the limb between you and the tree trunk.  Nothing stops you
from doing it.  In some cases it might even make sense to do it.  You
might really be on a boom-lift with a safety harness trimming a
particularly problem limb and it would be a shame if you were
prevented from doing it if that was what made sense at the time.

> It gives me the right path. But... Where am I realy? The output is:
> /var/folder

Remember that "pwd" is a shell builtin and the shell will report the
value that it has been tracking in $PWD.  It actually has stale data
there.  If you were to do /bin/pwd to force using the external one you
would see:

  /bin/pwd: couldn't find directory entry in `..' with matching i-node

The way that pwd determines the name of the current directory is by
walking upward through the ".." entries and matching i-nodes to
filenames.  Because there are no ".." entries there is effectively no
path to the current working directory.

The shell remembers where it was with $PWD and reports where it was
last known to be in order to report symlinks logically instead of
physically.

You can change directory from the orhaned directory to anywhere.  Or
you can exit the process.  Either way the reference count on the old
directory will be reduced to zero at which time the filesystem will
reclaim all of the space.

> And if i want to write something in this "imaginary" folder, like this:
> # echo "test" > test.txt
> 
> I get this output.
> bash: test.txt: No such file or directory

Yes.

> Now... Is this "bash problem", "rm problem" or "whatever problem"? :)

None of the above.  It is simply how Unix-like filesystems work.  It
does not dictate to you that you cannot do such a thing.

Think of this case as a contrived example of one way for this to be
useful.  A program can create a temporary directory in /tmp and change
directory to it.  It can create temporary files there.  When done the
program can remove the entire directory to clean up all of the
associated files.  Then the program can exit.  All clean.

Bob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]