4 ms·

There's an important difference between metadata owned by a file and metadata that a user/program has attached to a file. Metadata onwed by a file ought to be

There's an important difference between metadata owned by a file and metadata that a user/program has attached to a file. Metadata onwed by a file ought to be embedded in the file's data, so that it will be preserved if you copy the file to a different system. This is the case for images, pdf, mp3 etc. Metadata attached to a file is useful to simplify many 3rd-party programs, but should generally not be preserved if you copy the file. Stuff like display attributes for Finder, quarantine attributes for the virus scanner, etc. Each of these requirements deserves a different implementation approach, which is why the current state of affairs makes sense to me.

adrian_b 3y ago
I do not agree. Any file copy operation should by default make a perfect copy of the source file, without losing any kind of metadata, because that is the meaning of the word. It is not advertised as a partial copy command. Even when some metadata would be useless of the destination, the purpose of the copy may be to store temporarily the file in another place, with the intention to bring it back later to the original location, when no alteration should have happened to the file. If a complete copy cannot be done, e.g. because the destination file system cannot store some of the metadata, e.g. it has timestamps with a lower precision or it does not store some of the extended attributes, like the Linux tmpfs file system, the copy operation should fail with an explicit error message, like when the destination does not have enough space for all file data. Any file copy command should have options to strip some or all metadata from a file, when that is desired, but that should not be the default option. In the past I had unpleasant surprises with the Linux coreutils or with ssh, which lost silently metadata, even with the appropriate command-line options, which should not have been needed, in the case of coreutils because they had a compilation option to ignore the extended attributes and that option had been used in the binary packages available for certain Linux distributions. When copying over the network, I always use rsync over ssh, because it copies reliably all metadata, even between different operating systems and file systems, e.g. Linux, FreeBSD and Windows.
- zeroimpl 3y ago
  It's a matter of defaults, and no choice of default will work for everybody. I agree that "rsync --archive" ought to preserve extended attributes, same with creating a tarball. But when copying a file, as opposed to creating a backup/archive, I don't think extended attributes should be included by default. And yes I've also had to compile custom versions of rsync at one point to get a version which understood extended attributes on Mac, but I think that's mostly standardized now. EDIT: Also most programs don't even preserve permissions/ACLs on copy, so not sure why they'd preserve attributes by default.
  - adrian_b 3y ago
    Most copy programs do not preserve much or all metadata by default because this was the original behavior of the UNIX cp command, which copied only the file data, but none of the metadata, except the file name, when it was not specified for the destination. The first time when I have used cp, more than thirty years ago, it was a shock for me to discover that this is the default behavior, because it is not something that I can associate with a command named "copy". Since that day and until today, I always alias the various copy commands like cp or rsync to include all the necessary options for making perfect copies. I have never needed to use them with different options, which would make imperfect copies, but there have been countless situations when my usage would have been broken by lossy copies.

adrian_b 3y ago

I do not agree. Any file copy operation should by default make a perfect copy of the source file, without losing any kind of metadata, because that is the meaning of the word. It is not advertised as a partial copy command. Even when some metadata would be useless of the destination, the purpose of the copy may be to store temporarily the file in another place, with the intention to bring it back later to the original location, when no alteration should have happened to the file. If a complete copy cannot be done, e.g. because the destination file system cannot store some of the metadata, e.g. it has timestamps with a lower precision or it does not store some of the extended attributes, like the Linux tmpfs file system, the copy operation should fail with an explicit error message, like when the destination does not have enough space for all file data. Any file copy command should have options to strip some or all metadata from a file, when that is desired, but that should not be the default option. In the past I had unpleasant surprises with the Linux coreutils or with ssh, which lost silently metadata, even with the appropriate command-line options, which should not have been needed, in the case of coreutils because they had a compilation option to ignore the extended attributes and that option had been used in the binary packages available for certain Linux distributions. When copying over the network, I always use rsync over ssh, because it copies reliably all metadata, even between different operating systems and file systems, e.g. Linux, FreeBSD and Windows.

zeroimpl 3y ago
It's a matter of defaults, and no choice of default will work for everybody. I agree that "rsync --archive" ought to preserve extended attributes, same with creating a tarball. But when copying a file, as opposed to creating a backup/archive, I don't think extended attributes should be included by default. And yes I've also had to compile custom versions of rsync at one point to get a version which understood extended attributes on Mac, but I think that's mostly standardized now. EDIT: Also most programs don't even preserve permissions/ACLs on copy, so not sure why they'd preserve attributes by default.
- adrian_b 3y ago
  Most copy programs do not preserve much or all metadata by default because this was the original behavior of the UNIX cp command, which copied only the file data, but none of the metadata, except the file name, when it was not specified for the destination. The first time when I have used cp, more than thirty years ago, it was a shock for me to discover that this is the default behavior, because it is not something that I can associate with a command named "copy". Since that day and until today, I always alias the various copy commands like cp or rsync to include all the necessary options for making perfect copies. I have never needed to use them with different options, which would make imperfect copies, but there have been countless situations when my usage would have been broken by lossy copies.