current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 10 down vote favorite

I would expect

find . -delete

to delete the current directory, but it doesn't. Why not?

share|improve this question
2  
Most likely because removing the current working directory would not be a good idea. – Alexej Magura 9 hours ago
    
Agreed--I like the default behavior, but it is not consistent with, e.g., find . -print. – mbroshi 8 hours ago
    
@AlexejMagura although I sympathize, I do not see why removing the current directory should be any different than removing an open file. The object will stay alive until a reference to it exists, and then garbage collected afterward. You can do cd ..; rm -r dir with another shell with quite clear semantics... – Rmano 7 hours ago
    
@Rmano this is true: it's just something I wouldn't do on principle: just go up a directory and then delete the current directory. I'm not entirely sure why it's such a big deal--though I have had some misfortunes with the current directory no longer existing, such as relative paths no longer working, but you can always get out by using an absolute path--but some part of me just says that it isn't a good idea in general. – Alexej Magura 7 hours ago
up vote 11 down vote accepted

The members of findutils aware of it, it's for compatible with *BSD:

One of the reasons that we skip deletion of "." is for compatibility with *BSD, where this action originated.

The NEWS in findutils source code shows that they decided to keep the behavior:

#20802: If -delete fails, find's exit status will now be non-zero. However, find still skips trying to delete ".".

Keep in mind that find .. -delete is working, nothing to do with POSIX-conforming which dot-dot shouldn't allow.

share|improve this answer
up vote 11 down vote

Because your find command returns . as result. From the info page of rm:

Any attempt to remove a file whose last file name component is ‘.’ or ‘..’ is rejected without any prompting, as mandated by POSIX.

So, it looks like find just sticks to POSIX rules in this case.

share|improve this answer
2  
As it should: POSIX is king, plus removing the current directory could cause some very big problems depending on the parent application and what not. Like what if the current directory were /var/log and you ran that as root, thinking that it'd remove all the subdirs and it removed the current directory as well? – Alexej Magura 8 hours ago
    
That's a good theory, but the man page for find says: "If the removal failed, an error message is issued." Why is no error printed? – mbroshi 8 hours ago
up vote 2 down vote

The rmdir system call fails with EINVAL if the last component of its argument path is ".". It's documented at http://pubs.opengroup.org/onlinepubs/009695399/functions/rmdir.html and the rationale for the behavior is:

The meaning of deleting pathname /dot is unclear, because the name of the file (directory) in the parent directory to be removed is not clear, particularly in the presence of multiple links to a directory.

share|improve this answer
up vote 1 down vote

Calling rmdir(".") as a system call didn't work when I tried it, so no higher level tool can succeed.

You must delete the directory through its real name not its . alias.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.