-----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 [EMAIL PROTECTED] -----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/