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@cygwin.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/
