bug#48833: reflink copying does not check/set No_COW attribute and fail

[A L]

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