Mail Archives: cygwin/2005/08/27/04:45:11
On Aug 26 14:30, Eric Blake wrote:
> $ readlink u
> x
> $ ls x*
> x.exe
> $ ls -lF x
> - -rwxr-xr-x 1 eblake None 13961 Mar 10 06:54 x*
> $ file x # See below for more on this...
> x: writable, executable, regular file, no read permission
> $ ./myreadlink u/blah
> 'u/blah': NULL, 2 No such file or directory
>
> You are right that the code is correctly giving ENOTDIR when the symlink
> isn't half-dangling (ie stat() succeeds but open() fails):
> $ readlink u.exe
> x.exe
> $ ./myreadlink u/blah
> 'u/blah': NULL, 20 Not a directory
That's a result of attaching .exe to symlinks. When iterating over
paths, the .exe suffix is only checked on the last component, never
on inner (== directory) components. This makes sense, otherwise every
component has to tested twice as often, which would slow down Cygwin
a lot. I don't see a good reason to change that, just for the
(questionable) success, to exchange one errno for another.
After all, EINVAL is correct, as would be ENOTDIR. I don't see that
POSIX demands an order of errnos in the case where two or more different
errnos are correct. For instance, consider a function which treats
the first parameter as invalid if it's NULL, and which copies something
into the space where the second parameter points to:
int err = foo (NULL, (void *) 0x01);
Which errno is correct to return, EINVAL or EFAULT?
Btw., what was the exact reason to attach the .exe suffix to symlinks
pointing to executables? I fail to see the advantage, right now.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
--
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 -