[coreutils] cp cannot preserve xattr

Version:

coreutils-7.1 (fixed in version 8.0)

How to reproduce the failure:

$ touch xattr_test_file

$ setfattr -n user.XXX -v "test" ./xattr_test_file

 -- this is to set the extended file attribute. See some explanations on xattr here:

http://wiki.kaspersandberg.com/doku.php?id=howtos:xattr

$ chmod a-w ./xattr_test_file

 -- this bug can only be reproduced without the write permission

$ coreutils-7.1/src/cp --preserve=xattr ./xattr_test_file ../

Sympom:

$ ./cp --preserve=xattr ../file .

$ ./cp: setting attribute `user.XXX' for `user.XXX': Permission denied

  --- The copy failed to copy the file and printed the above error message.

        Note that the above error message was printed within a library function: ‘attr_copy_fd’, and we cannot find any string pattern within the source code of ‘cp’. In other words, we do not know the source code location of this error, thus do not know where to start our search!

Root cause:

‘attr_copy_fd’, a library function that performs copy of x-attributes, requires the source to have write permission. The fix is temporarily give write permission for the source, and after the copy revoke back!

Comments written by us are in blue.

static bool copy_attr_by_fd (char const *src_path, int src_fd, char const *dst_path, int dst_fd) {

 /* The ‘copy_attr_error’ is a function pointer, that will print */

struct error_context ctx =

 {

   .error = copy_attr_error,

   .quote = copy_attr_quote,

   .quote_free = copy_attr_free

 };

  /* Because the source file do not have write permission, the

   * created destination file also do not have write permission.

   * However, ‘attr_copy_fd’ requires the destination file

   * has write permission. Thus in the buggy execution this

   * attr_copy_fd failed and returned 1. */

  /* The fix is to temporarily give destination file write permission,

   * and after the attr_copy_fd,

   * it immediately reclaimed the write permission back. */

  return 0 == attr_copy_fd (src_path, src_fd, dst_path, dst_fd, 0, &ctx);

}

Is there error message?

Yes.  (although it is from the library, so we cannot directly map it back to the source code location).

Can Errlog anticipate the failure?

Yes. It is of the pattern: library call returned error status. Errlog automatically annotate and intercept the error return value of attr_copy_fd.

The proposed error message + relevant variable values identified by LogEnhancer is sufficient to diagnose the failure!