From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18944 invoked by alias); 27 Feb 2011 08:57:06 -0000 Received: (qmail 18936 invoked by uid 22791); 27 Feb 2011 08:57:05 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-qw0-f67.google.com (HELO mail-qw0-f67.google.com) (209.85.216.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 27 Feb 2011 08:57:01 +0000 Received: by qwh5 with SMTP id 5so461927qwh.2 for ; Sun, 27 Feb 2011 00:56:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.246.196 with SMTP id lz4mr3204823qcb.39.1298782133823; Sat, 26 Feb 2011 20:48:53 -0800 (PST) Received: by 10.229.80.1 with HTTP; Sat, 26 Feb 2011 20:48:53 -0800 (PST) In-Reply-To: <4D685151.5020602@towo.net> References: <20110217120400.GB29762@calimero.vinschen.de> <4D600C0A.9080305@etr-usa.com> <4D6273C4.9050406@redhat.com> <4D6282CF.1000606@towo.net> <4D685151.5020602@towo.net> Date: Sun, 27 Feb 2011 11:21:00 -0000 Message-ID: Subject: Re: Please test latest developer snapshot From: Vorfeed Canal To: Thomas Wolff Cc: cygwin@cygwin.com Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-02/txt/msg00568.txt.bz2 Message-ID: <20110227112100.vyga_1ovwtN65OBtq-K8bssrUsTap3aR5GFiujVBXLo@z> On Sat, Feb 26, 2011 at 4:03 AM, Thomas Wolff 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