delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2005/10/12/10:28:02

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: ericblake AT comcast DOT net (Eric Blake)
To: cygwin AT cygwin DOT com
Subject: Re: mkdir(2) bug [Was: please test: coreutils-5.90-2]
Date: Wed, 12 Oct 2005 14:27:48 +0000
Message-Id: <101220051427.9361.434D1D6400077ADE0000249122007610640A050E040D0C079D0A@comcast.net>

> 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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019