|
From: | Linda Walsh |
Subject: | bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail) |
Date: | Thu, 27 Mar 2014 07:10:33 -0700 |
User-agent: | Thunderbird |
Eric Blake wrote:
On 03/26/2014 10:44 PM, Linda Walsh wrote:cp has a workaround for directories and it has exactly this workaround on other OS that don't support hardlinking.That "workaround" is behavior mandated by POSIX, and has existed prior to POSIX even being standardized.I don't see why this shouldn't be treated similarly to the 2nd case, as the OS no longer supports hardlinking in as many cases as it used to -- so why shouldn't it fall back?It's better to not second guess the kernel; you may want to take this up on the kernel lists if you want something changed.
--- It's not second guessing -- it's responding to a lower capability (or lessprivileged) environment. It also depends on whether or not those features are turned on (i.e. by assigning 0/1 to /proc/sys/fs/paranoid_protected_{hard,soft}links). AFAIK, my vendor may have them set somewhere in boot code I haven't audited ( -- I've never had a need to audit my startup code till they started forcing systemd down everyone's throat
and putting dummy wrapper calls in the sysVinit code). I.e. they've converted it from a system where doing a 'cp -al' workedreliably to one where it doesn't. If it doesn't work reliably, then it seems the, *cough*, posix mandate should followed....
But the outcome would be that cp would still just work -- just within the bounds of what it is allowed to do. Instead the attitude seems to be, gosh if we can't have it the way it was, we shouldn't try to have it all. The kernel bug is a separate issue -- since I CAN link to the file (permissions allow it), but the same permissions on the link are ignored. Note -- I grant that permissions ANd ownership on symlinks have always been ignored (at least in experience), but if they are going to start using permissions to enable/disallow hardlinking, maybe they shouldn't carve out a special exception for symlinks. But those are separate for how cp should behave on filesystems with varying, "assumed" capabilities...(i.e. failing because one can't link to a symlink when linking to symlinks isn't a requirement for this to be allowed on systems that don't support symlinking at all). I.e. as it stands, the ability to hardlink to a file is dependent on what features and policies your kernel has built in. Cp should work as well as possible regardless of those policies.I.e. what is the posix policy for handling linking requests when the OS has disabled them? If they wanted to disable copying the tree, they would make
it non-readable.
[Prev in Thread] | Current Thread | [Next in Thread] |