Messages in this thread | | | Date | Mon, 8 Jan 2001 12:58:20 -0500 (EST) | From | Alexander Viro <> |
| |
On Mon, 8 Jan 2001, Andrea Arcangeli wrote:
> Hello Al, > > why `rmdir .` is been deprecated in 2.4.x? I wrote software that depends on > `rmdir .` to work (it's local software only for myself so I don't care that it > may not work on unix) and I'm getting flooded by failing cronjobs since I put > 2.4.0 on such machine. `rmdir .` makes perfect sense, the cwd dentry remains > pinned by me until I `cd ..`, when it gets finally deleted from disk. I'd like > if we could resurrect such fine feature (adapting userspace is just a few liner > but that isn't the point). Comments?
It's a hell of a pain wrt locking. You need to lock the parent, but it can cease to be your parent while you were locking it. rmdir() (and especially rename()) are major PITA as is. Adding lock/check/retry everything if we had been moved was way over the top. Again, rename() was the main offender, but rmdir() also wasn't nice.
rmdir() and rename() act on links. Yes, for directory there is a special link - one from the parent and we could try to find it and assume that caller wanted to do the thing on said link. However, it _is_ overloading the operation. Adds quite a bit of complexity into the place where we already have too much. For no good reason, since rmdir(pwd) does the same thing quite fine, is portable (unlike the rmdir(".") which will fail on every UNIX except Linux) and does not require special-casing.
All namespace-modifying operation (create/remove/rename) act on the links, not fs objects. Pathname you are passing identifies the directory entry that should be affected. Conceptually, actual removal of the inode is a side effect.
The bottom line: rmdir(".") is gone. Replace it with portable equivalent, namely p = getcwd(pwd, sizeof(pwd)); if (!p) /* handle error - ERANGE or ENOENT */ rmdir(p); Shell equivalent is rmdir `pwd`. Also portable. Same goes for rename(). Notice that _all_ pathes that end on . or .. are off-limits. Explicit POSIX requirement and in that case I'm 100% agree with them. Linux used to provide an extension that * added complexity (and was handled with races in 2.2) * was absolutely nonportable * was inconsistent with the semantics of other operations (and in case of rename() - with other parts of rename() semantics) * had simple portable replacement.
He's dead, Jim.
PS: try your code on any other UNIX and see it misbehave.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |