Below is the table of how I think ln(1) ought to behave (I'm open to
suggestions if others think differently). Where ln(1) does not actually behave
this way, I am open to help in patching coreutils to provide the desired
functionality. Hopefully my webmail interface didn't screw up this table too
badly.
existing: a a.exe both neither
ln a b 1 4 4 0
ln a.exe b 0 2 2 0
ln a b.exe 3 4 4 0
ln a.exe b.exe 0 4 4 0
ln -s a b 5 6 5 7
ln -s a.exe b 9 8 8 9
ln -s a b.exe 10 11 10 12
ln -s a.exe b.exe 14 13 13 14
results:
0. error
1. b is hardlink to a
2. b is hardlink to a.exe
3. b.exe is hardlink to a
4. b.exe is hardlink to a.exe
5. b is symlink, readlink b gives a, resolves to a
6. b is symlink, readlink b gives a, resolves to a.exe
7. b is symlink, readlink b gives a, dangling link
8. b is symlink, readlink b gives a.exe, resolves to a.exe
9. b is symlink, readlink b gives a.exe, dangling link
10. b.exe is symlink, readlink b.exe gives a, resolves to a
11. b.exe is symlink, readlink b.exe gives a, resolves to a.exe
12. b.exe is symlink, readlink b.exe gives a, dangling link
13. b.exe is symlink, readlink b.exe gives a.exe, resolves to a.exe
14. b.exe is symlink, readlink b.exe gives a.exe, dangling link
I guess one final question is whether cygwin's readlink(2) should be allowed to
append .exe if that's what the symlink currently resolves to, or if it should
always return exactly what is contained in the link. My table above assumes
that readlink(2) does not auto-append .exe when resolving a symlink.
--
Eric Blake
(coreutils maintainer)