Mail Archives: cygwin/2005/04/06/01:23:57
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/
- Raw text -