Re: 'cp -lL' behaviour conflicts with documentation

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Paul Eggert on 3/16/2005 1:53 AM:
>>$ touch a
>>$ ln -s a b
>>$ ln b c      # Bug: c should be a hard link to a, not b
>>$ ls -l a b c
>>-rw-r--r--  1 eblake None 0 Mar 15 19:04 a
>>lrwxrwxrwx  2 eblake None 1 Mar 15 19:04 b -> a
>>lrwxrwxrwx  2 eblake None 1 Mar 15 19:04 c -> a
> 
> It does seem to be a messy area.  It's not clear to me that POSIX was
> intended to specify what it does.  Personally I prefer the GNU "ln"
> behavior, on hosts that support hard links to symlinks: it's much
> cleaner and easier to explain.
> 
One more point to consider.  With GNU behavior, the next command of `rm a'
leaves both `b' and `c' as dangling pointers, and loses the file; while
with POSIX behavior, `rm a' leaves `b' dangling, but `c' still contains
the contents of `a' so no data has been lost (provided you know its
alternate name).  It comes down to a question of whether creating the hard
link named c should preserve the metadata (b is a symlink to a) or the
data (the contents of a), when someone is using hard links to avoid data
loss.  Both behaviors seem reasonable, so it is probably worth a
command-line option in ln.

> Maybe this should be brought before the POSIX committee?
>
I agree, and just posted the issue to the austin group.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCODqn84KuGfSFAYARAmw3AKDQ/RUwsJHr0JbWTLbwMYln7IsRRQCgxfS5
Je7Wcyqot1gBGAiQWqLrCoM=
=wV/t
-----END PGP SIGNATURE-----