Subject: bug#12400: rmdir runs "amok", users "curse" GNU...(as rmdir has no option to stay on 1 file system)...

From: Bob Proulx <[email-masked]>
Date: Sun, 9 Sep 2012 23:22:31 -0600

Linda Walsh wrote:
> If you are going to only provide 1 mode of functionality, it should
> be to only rmdir dirs on the same file system as the starting args.

But rmdir really only removes the directories you tell it.  What is
the command you are complaining about?  Are you using --parents or
something?

> Instead it follows network mount points doing who knows what.

Doing rmdir?

> I already know that it has in the past, on network'd file systems,
> gone ahead and did a 'pre-delete' on a dir that read as 'unwritable'
> due to files being in the dir -- and renamed it to some obscure name
> for later processing when it thought it would make a difference.

You are probably talking about the nfs last close problem.  NFS
renames files to a .nfsXYZ where XYZ is a unique random string.  If it
were a local stateful filesystem it would be able to implement this
correctly.  But for a remote networked filesystem it can only be
emulated by doing thins like renaming.  Search for nfs last close
problem and you will see the issue.

> Having rmdir follow all network mounts and deleting remote files would seem
> to be a nasty potential security issue.

But rmdir only removes the directories you tell it to remove.

> Note, using shell to do this, is the normal recommended way to do this,
> just like rm I'm told, is the recommended solution, so
> following those instructions, I tried to use "rmdir **", (since rmdir has
> no recursive option, it is mandatory to use shell.

There are two pieces there.  One is that the shell, if it is one of
the magic shells that supports **, will expand that into an explicit
list of option arguments for the rmdir command.  The other is the
rmdir command which will simply get a list of option arguments.  By
doing it that way there is no way for rm to know that they are
anything other than explicitly named directories to be removed.

If you want a recursive option why not use 'rm -rf'?

There is always 'find' with the -delete option.  But regardless there
has been the find -exec option.

  find /some/path -type d -delete

  find /some/path -depth -type d -exec rmdir {} +

Bob