Mail Archives: cygwin/2011/02/27/02:37:40
On Sat, Feb 26, 2011 at 4:03 AM, Thomas Wolff <towo AT towo DOT net> wrote:
> No, what used to work (and didn't work in cygwin for a while) is that the
> current directory of some process is removed, not mentioning how it could be
> removed.
Sure, this is pre-requisite of rmdir("."). I was specifically talking about
rmdir(".") and rmdir("..").
> It cannot be removed by "rmdir ." for the reasons I mentioned.
Well, may be it can not be done in CygWin for some internal reasons but it
was possible to do that in Linux for a long time - till it was explicitly
forbidden.
> It can only be removed by using its full path, or relative path from its parent
> directory. The parent directory must be referred explicitly, otherwise it
> cannot work - because, as I tried to explain, the semantics of removing a
> directory entry (whether file or subdirectory) could not be established.
>
It can be established and it was established in Linux 15 years ago.
> Actually, in traditional Unix terminology, directories were also special
> files; moreever, there could even be hard links of directories - but that
> doesn't contribute to the issue.
>
Oh, but it does. Sure, long time ago directories were just "files+" and you had
no need for getdents(2) and Co. But as long as directories are just a special
files and you are allowed to make hardlinks you can corrupt filesystem from
userspace using standard Unix API. Not good(tm). Thus small alteration was made:
".." entity. It was introduced to make sure you are not introducing loops (you
can traverse back to the root using chains of ".." and see that you are not
corrupting the tree).
But the introduction of ".." and special functions needed to manipulate the tree
made it perfectly fine to do rmdir(".") - there are not ambguity from this point
on!
> This conclusion is not correct. The code you seem to refer to is just a way
> of handling an error that would otherwise go unhandled and produce problems.
No, it'll not produce problems. It'll just work(tm). Well, may be it'll produce
problems today (it's possible there are some other places in kernel which depend
on these checks today), but it certainly worked in Linux for a long, long time
without any ill effects (except for some brain-dead scripts). Long enough to
paper over the problem in rmdir(1)...
> Error handling is not a limitation.
It's the only limitation.
> Further down in the code, where the actual removal is invoked, the code needs
> the parent directory which it would not have in the case guarded by the error
> checking.
Why do you think so? Parent directory is ALWAYS available via ".."
entity. In some
case it's not available (for example if it's the root of the filesystem) - well,
in this case rmdir(".") obviously can not work.
Sure, in original Unix design where ".." was convenience, not a requirement it's
not possible to make rmdir(".") work, but these Unix system were extinct for so
long that we may happily forget about them.
P.S. Actually in modern Unix systems (including Linux) ".." entity does not
exist on disk - but it's strictly enforced in VFS layer so it does not change
anything conceptually: rmdir(".") makes perfect sense in Unix filesystem
and the ONLY reason it does not work on modern Unix systems is explicit
prohibition in POSIX.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -