On 2021-06-08 04:41, Zygo Blaxell wrote:
 > On Sun, Jun 06, 2021 at 10:47:05PM -0700, Paul Eggert wrote:
 >> On 6/5/21 10:42 PM, Zygo Blaxell wrote:
 >>> If cp -a implements the inode attribute propagation (or 
inheritance), then
 >>> only users of cp -a are impacted.  They are more likely to be aware 
that
 >>> they may be creating new files with reduced-integrity storage 
attributes.
 >>
 >> True, although I think this aspect of attribute-copying will 
typically come
 >> as a surprise even to "cp -a" users.
 >
 > Existing users might be surprised when "cp -a" starts replicating storage
 > attributes when it did not do so before, but I suspect most future cp
 > users would expect "cp -a" to preserve storage-policy attributes the same
 > way it currently preserves ownership, permissions, timestamps, extended
 > attributes, and security context--a list that initially contained only
 > the ownership, permissions, and timestamps in the past, the others were
 > added over time.  If not by default, then at least have the ability to
 > do it when requested with a "--preserve=datacow" switch.

...

 > The cp doc could be clearer that filesystems that support reflink
 > don't guarantee every file can be reflinked to every other file.
 > reflink is expected to fail in a growing number of cases over time,
 > as more filesystem features are created that are incompatible with it
 > (e.g. encryption, where reflinks between files with different owners 
could
 > be unimplementable).  I've seen a number of users get burned by 
making big
 > --reflink=always copies and not checking the results for errors, assuming
 > that only lack of space for metadata could cause a reflink copy to fail.
 > There are good reasons why --reflink=auto exists and is the default,
 > and users ignore them at their peril.
 >

Hello everyone,
I made a similar thread[1] about a year ago on the coreutils 
mailing-list and I think it is also relevant to this bug-report.

It is true as Zygo mentions, that reflinking nocow and cow files does 
not work, and cannot work due to the nature of how nocow works.

What I would like to add to this bug-report is what elaborated on in the 
other thread, that we can move forward with preserving all attributes by 
setting them in the correct order. I show in the message that reflinking 
works between two nocow files and that ‘cp -a’ could preserve nocow and 
other attributes if ‘cp -a’ sets those attributes in correct order.

As a normal end-user, IMHO, ‘cp -a’ should preserve all attributes where 
possible, which is also what the manual[2] currently states:

‘--archive’
Preserve as much as possible of the structure and attributes of the 
original files in the copy (but do not attempt to preserve internal 
directory structure; i.e., ‘ls -U’ may list the entries in a copied 
directory in a different order). Try to preserve SELinux security 
context and extended attributes (xattr), but ignore any failure to do 
that and print no corresponding diagnostic. Equivalent to -dR 
--preserve=all with the reduced diagnostics.


Only when using --reflink=always, we should fail if the target cannot 
support reflinks.

Thanks!

~A


[1] https://lists.gnu.org/archive/html/coreutils/2021-06/msg00005.html that
[2] 
https://www.gnu.org/software/coreutils/manual/html_node/cp-invocation.html#cp-invocation