This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with sh/bash and snapshot cygwin1-20050825.dll


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 8/27/2005 2:44 AM:
> 
> 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.

OK - I see what is happening.  When u (not u.exe) is a symlink to x
(although only x.exe exists), then path resolution of u/something tries to
dereference u, looks for directory x, and since no x exists, reports
ENOENT instead of ENOTDIR.  And this is correct, since there really is no
x.  This is a case where u is a half-broken symlink - for the purposes of
exec*(), u resolves to x.exe, but for the purposes of open(), u fails to
resolve with ENOENT.  So there is no bug in realpath() in this regards.

> 
> Btw., what was the exact reason to attach the .exe suffix to symlinks
> pointing to executables?  I fail to see the advantage, right now.

Which .exe are you asking about?  If only x.exe exists, and you do 'ln -s
x u', there are several options:
create u, pointing to x (u is half-broken - it works in exec but not open)
create u, pointing to x.exe (u is a working symlink, but 'readlink u' does
not show the user's spelling, and there is no indication the magic happened)
create u.exe, pointing to x.exe (u is a working symlink, and the extension
to u hints why the user's spelling was changed)

Right now, coreutils does the latter.  Furthermore, the current extension
search order of cygwin is none, .exe, .exe.lnk, and then .lnk, so naming a
link to an .exe with .exe is slightly faster than leaving the .exe off
(although it does seem a bit inconsistent to me that if both x and x.exe
are regular files, stat("x") finds x, but if both are symlinks, stat("x")
finds the x.exe link).

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDEIY084KuGfSFAYARAqvpAJ9jIZg7N2/d4YPKBQApyLRwNttXPgCgyQh8
NCEVMRFZobvnUT24R1p0kIs=
=0e7C
-----END PGP SIGNATURE-----

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]