bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15173: [cp] --link overrides dereference settings


From: Gian Piero Carrubba
Subject: bug#15173: [cp] --link overrides dereference settings
Date: Thu, 31 Oct 2013 14:54:59 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

* [Thu, Oct 31, 2013 at 12:12:55PM +0000] Pádraig Brady:
On 10/30/2013 01:13 PM, Bernhard Voelker wrote:
The changes so far - 12 out of 144 - are:

  $ grep "DIFFERENCE in Test: " testit.log | sed 's/^.*: //'
  cp -L -l   filelink ...
  cp -L -l  --preserve=links filelink ...
  cp -L -l -R  filelink ...
  cp -L -l -R --preserve=links filelink ...
  cp -H -l   filelink ...
  cp -H -l  --preserve=links filelink ...
  cp -H -l -R  filelink ...
  cp -H -l -R --preserve=links filelink ...

So -HL are now honored in this regard

  cp  -l   dirlink ...
  cp  -l  --preserve=links dirlink ...
  cp  -l   danglink ...
  cp  -l  --preserve=links danglink ...

and by default we don't deref the above.

That all seems consistent with expectations and what we previously discussed.

Not what I would expect, and imho not SUSv3 compliant, either with regard to --preserve=links and -R. More about this later.

I've just now read POSIX for cp, and it states:

"If the -R option was not specified, cp shall take actions based on the type
 and contents of the file referenced by the symbolic link, and not by the
 symbolic link itself, unless the -P option was specified."

This suggests that -HL should only be significant with -R ?
That is a bit surprising TBH. What do you think Eric?

Oh well, didn't read it like this. My opinion was, and still is even if not strong as before, that explicitly using -H/L/preserve=links would override that _default_ behaviour.

I wouldn't be inclined to follow POSIX in that regard.

Oh... I was tweaking a bit the last patch posted by Bernhard in order to let it be POSIX compliant (but now I have to add: "for my interpretation of POSIX"), but didn't had the time to complete before going to work. Will probably finish it up anyway this evening or tomorrow, at this point at least for comparing how far we're currently are from "POSIX". In the meantime please see attached the results for the tests from Bernhard. There are a lot more differences in behaviour:

$ fgrep -c "DIFFERENCE in Test: " testit.log
40

but I suspect (I hadn't the time for double checking them) they are all correct.

My points in short:

- POSIX (my interpretation): without '-r' the link should be dereferenced, *unless* told otherwise - POSIX (I think, cannot check now): order of options is important. In case of conflicting options, the LAST one should be used
- --(no)-preserve=links
To be honest, it isn't clear to me what it stands for. I have assumed --preserve=links should set DEREF_NEVER and --no-preserve=links should set DEREF_ALWAYS. Anyway I don't particularly like the implementation, as now dereferencing settings are both in x->preserve_links and in x->dereference, some times even with opposite values. And some times a function checks for x->preserve_links and not for x->dereference, or vice versa. If it has a different meaning from what I've supposed, I can't understand how it should behave.

Frankly, dereferencing in cp seems a bit more complicated as I first supposed.

Ciao,
Gian Piero.

Attachment: testit.log.gz
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]