Eric Blake schrieb: ...
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)
Eric, Just a big thank you, that you are doing a really great job!
-- Reini Urban http://xarch.tu-graz.ac.at/home/rurban http://phpwiki.org
-- 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/
