From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18439 invoked by alias); 12 Oct 2005 14:27:53 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 18419 invoked by uid 22791); 12 Oct 2005 14:27:50 -0000 Received: from rwcrmhc11.comcast.net (HELO rwcrmhc11.comcast.net) (204.127.198.35) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 12 Oct 2005 14:27:50 +0000 Received: from 204.127.197.119 (rmailcenter79.comcast.net[204.127.197.179]) by comcast.net (rwcrmhc11) with SMTP id <2005101214274801300jnj4re>; Wed, 12 Oct 2005 14:27:48 +0000 Received: from [128.170.36.44] by 204.127.197.119; Wed, 12 Oct 2005 14:27:48 +0000 From: ericblake@comcast.net (Eric Blake) To: cygwin@cygwin.com Subject: Re: mkdir(2) bug [Was: please test: coreutils-5.90-2] Date: Wed, 12 Oct 2005 14:27:00 -0000 Message-Id: <101220051427.9361.434D1D6400077ADE0000249122007610640A050E040D0C079D0A@comcast.net> X-SW-Source: 2005-10/txt/msg00303.txt.bz2 > On Oct 12 06:58, Eric Blake wrote: > > I see the following bugs: > > > > $ ./foo // # should fail with EEXIST, not EROFS; no Windows call made > > We had this already. There's no such thing as a "correct" order of error > messages. EROFS is as correct as EEXIST. If coreutils don't allow > different correct error messages to be returned, than coreutils is just > not foolproof enough. If this isn't a problem with coreutils, than the > better. OK, for //, you win - POSIX requires EROFS ONLY if the PARENT directory is read only, but the parent of // is //. Fortunately, mkdir -p never tries to do mkdir("//"). > > > $ ./foo /proc # should fail with EEXIST, not EROFS > > /proc: 30 Read-only file system > > See above. But for /proc, you are wrong - the parent directory / is not read only, so POSIX only allows mkdir("/proc") to fail with EEXIST and not EROFS. > > > $ ./foo c: # should fail with EEXIST, not EACCES > > See my previous mail on this subject. Isn't it just a matter of checking if the original filename was a drive letter (a simple string comparison, no windows calls at all), and only on the error path of EACCESS (so it won't penalize the normal successful path)? > > > $ ./foo a/. # should fail with EEXIST, not ENOENT > > a/.: 2 No such file or directory > > I get ENOENT on Linux. When? Before or after a exists? It makes a difference (this trace is on Solaris 8): % ls a ls: a: No such file or directory % ./foo a/. a/.: 2 No such file or directory % ./foo a/ a/: 0 Error 0 % ./foo a/. a/.: 17 File exists Cygwin is blindly returning ENOENT, without first checking whether a/ exists. ENOENT is only permitted if a doesn't exist; otherwise it must be EEXIST. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/