Re: Difference in ln/ln -s semantics

[Vitali Lovich]

How about for symlinks: "When creating symbolic links, each TARGET path will
be resolved relative to the parent directory of the symbolic link when it is
accessed" below the "When creating hard links, each TARGET must exist."
text.

Is it too sutble that this may be a problem for relative paths?  "ln" man
page already contains a link to the symlink man page - but it's probably
unlikely that someone using the tool is going to bother looking at the
system call behind it.

Vitali

2009/2/2 Eric Blake <address@hidden>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Jim Meyering on 2/2/2009 6:06 AM:
> >>
> >>   For semantic differences between ln and ln -s see the examples
> section.
> >
> > Thanks.  Either would be good.
> > Would you like to adjust doc/coreutils.texi accordingly?
>
> The coreutils.texi documentation is already lengthy:
>
> |    A "hard link" is another name for an existing file; the link and the
> | original are indistinguishable.  Technically speaking, they share the
> | same inode, and the inode contains all the information about a
> | file--indeed, it is not incorrect to say that the inode _is_ the file.
> | On all existing implementations, you cannot make a hard link to a
> | directory, and hard links cannot cross file system boundaries.  (These
> | restrictions are not mandated by POSIX, however.)
> |
> |    "Symbolic links" ("symlinks" for short), on the other hand, are a
> | special file type (which not all kernels support: System V release 3
> | (and older) systems lack symlinks) in which the link file actually
> | refers to a different file, by name.  When most operations (opening,
> | reading, writing, and so on) are passed the symbolic link file, the
> | kernel automatically "dereferences" the link and operates on the target
> | of the link.  But some operations (e.g., removing) work on the link
> | file itself, rather than on its target.  *Note Symbolic Links:
> | (libc)Symbolic Links.
>
> [By the way, POSIX 2008 mandates symlinks on all systems; about the only
> system worth porting to these days that still lacks symlink support is the
> non-POSIX mingw]
>
> > If you change the man page (aka --help output), bear in mind
> > that is should stay concise.  It does point to the complete
> > documentation in the info pages after all.
>
> The trick is coming up with a concise statement for the --help output
> which might help here.
>
> - --
> Don't work too hard, make some time for fun as well!
>
> Eric Blake             address@hidden
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Public key at 
> home.comcast.net/~ericblake/eblake.gpg<http://home.comcast.net/%7Eericblake/eblake.gpg>
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmG8T4ACgkQ84KuGfSFAYB//ACbBjudPs+E8lL43aNjMoFAuydV
> 8vIAn3XG2SrrSqSqzZ3W6ERvPJra4T7N
> =GWSF
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Bug-coreutils mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-coreutils
>