[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 'cp -lL' behaviour conflicts with documentation
From: |
Eric Blake |
Subject: |
Re: 'cp -lL' behaviour conflicts with documentation |
Date: |
Wed, 16 Mar 2005 06:54:48 -0700 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
-----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-----