4 ms·

But what you're referring to here are the attributes that the file system stores about the file, not the file itself. By default I wouldn't expect a copy of a f

But what you're referring to here are the attributes that the file system stores about the file, not the file itself. By default I wouldn't expect a copy of a file to have identical file system attributes, just an identical content for the file. I would expect some of the file system attributes to be copied, but not all of them. Take the file owner for example if I take a copy of a file then by default I should be the owner of that file as it's my copy of the file, and not the original file owner's copy. An alternative way of looking at it is if I have created a file on my local machine that's owned by root and has the setuid bit set on it's file permissions then there's no way that I should be able to copy that file up to a server with my normal user account and have those atttibutes still set on the copy.

LoganDark 2y ago
"File" means an entry in the file system, and so includes the metadata. It is not only the data. When a copy a file you will be the owner because the new copy is your copy. Other attributes however like modification date for example will remain the same. It's not as if you wrote the contents of the file anew, especially not for copy-on-write architectures like Apple's APFS.
- scrapheap 2y ago
  So you also would expect some of the file system attributes to be copied, but not all of them. :D
  - LoganDark 2y ago
    I expect all of them to be copied except for specifically the owner and group. Created date, modified date, ACLs, extended attributes, eeeverything else. My expectations are more specific than "not all of them", so please don't misrepresent them.
    - scrapheap 2y ago
      Out of interest, why wouldn't you expect the created timestamp for a file that you've created by copying another file to be the point in time which the copy was made? After all, before that moment the file didn't exist, and after that moment it did.
      - LoganDark 2y ago
        macOS has "date added" for this, which is the date the file was added to its containing folder. It's not the exact same as the date created that you're talking about, though. I honestly don't have a strong preference either way on this. I don't use date created except for misbehaving media downloaders that think the file modified date is a good place to put the video publication date. I'm sure there's a flag somewhere that I don't care enough to find.
      - brulard 2y ago
        For some context you may want the new file creation time, but if I copy a folder of some backups for example, I don't want every file to have date set for today. I'll lose the possibility to filter files based on creation date, which is very useful for such use case. I don't remember that I would ever need a copy to have creation date reset.
      - Galanwe 2y ago
        Most tools that sync files (in contrast to mere copies) need a way to know which files need to be copied, and which can be skiped. The expensive way is to perform a checksum, but most sync tools rely on the creation or modified date unless told otherwise. Now say Alice and Bob have the same copy of file F, Bob modifies it first which gets stored at timestamp T, then Alice modifies her copy at time T+1. Bob syncs his files on a filer, its timestamp gets reset to now, which is say T+2. Then Alice does the same, but her file does not get copied, since the remote timestamp T+2 is newer than her local timestamp T+1.
    - account42 1y ago
      You do you expect the ACL to be copied but not the owner? They are different abstractions of the same thing.
bayindirh 2y ago
As a counterpoint, many daemons or programs (e.g.: sshd, ssh, slurm, munge to name a few) expect their files to have specific users, groups and modes for security and behavioral guarantees, and flat out refuse to run if these requirements are not met. When installing these things from archives or moving/distributing relevant files to large fleets, I expect the file contents and all metadata incl. datestamps to be carried the way I want, because all of that data is useful for me and the application which uses the file. If the user doing the copying has no right to copy the file exactly, I either expect a loud warning or an error depending on the situation.
- op00to 2y ago
  Should the SELinux context of a file always be copied from the source when moving or copying it? Or should it typically inherit the context defined by policy for the destination directory structure? For example, copying a file from a user's home directory (perhaps user_home_t) into /var/www/html/ usually requires it to get the httpd_sys_content_t context (or similar) to be served by the webserver correctly and securely. Blindly copying the original user_home_t context would likely prevent the webserver from accessing the file. Doesn't this suggest that some metadata, specifically the SELinux context, often shouldn't be copied verbatim from the source but rather be determined by the destination and the system's security policy?
  - bayindirh 2y ago
    What if the tool accessing the file is malicious, and can copy the file, but can't change the context of the said file? SELinux shall be strict on its behavior even if it's a detriment to user convenience. SELinux contexts shall be sticky, and needs to be manually (re)set after copying. This is the default behavior, BTW. SELinux contexts are not (re)set during copy operations in most cases, from my experience. You need to change/fix the context manually.
    - op00to 2y ago
      I think when I cp a file it takes on the context of the directory or whatever the default context for that path is supposed to be, and when I mv, it retains the original context.
bmacho 2y ago
> But what you're referring to here are the attributes that the file system stores about the file, not the file itself. Yes. Sometimes you need that additional information too. And if you do, then rsync is your tool. If you only need the data stored in the file, then drag & drop suffices.
mannyv 2y ago
The executed bit is an attribute that the FS stores about the file, and isn't technically part of the file itself. Strip all the execute attributes out of your *nix system and see what happens.

LoganDark 2y ago

"File" means an entry in the file system, and so includes the metadata. It is not only the data. When a copy a file you will be the owner because the new copy is your copy. Other attributes however like modification date for example will remain the same. It's not as if you wrote the contents of the file anew, especially not for copy-on-write architectures like Apple's APFS.

scrapheap 2y ago
So you also would expect some of the file system attributes to be copied, but not all of them. :D
- LoganDark 2y ago
  I expect all of them to be copied except for specifically the owner and group. Created date, modified date, ACLs, extended attributes, eeeverything else. My expectations are more specific than "not all of them", so please don't misrepresent them.
  - scrapheap 2y ago
    Out of interest, why wouldn't you expect the created timestamp for a file that you've created by copying another file to be the point in time which the copy was made? After all, before that moment the file didn't exist, and after that moment it did.
    - LoganDark 2y ago
      macOS has "date added" for this, which is the date the file was added to its containing folder. It's not the exact same as the date created that you're talking about, though. I honestly don't have a strong preference either way on this. I don't use date created except for misbehaving media downloaders that think the file modified date is a good place to put the video publication date. I'm sure there's a flag somewhere that I don't care enough to find.
    - brulard 2y ago
      For some context you may want the new file creation time, but if I copy a folder of some backups for example, I don't want every file to have date set for today. I'll lose the possibility to filter files based on creation date, which is very useful for such use case. I don't remember that I would ever need a copy to have creation date reset.
    - Galanwe 2y ago
      Most tools that sync files (in contrast to mere copies) need a way to know which files need to be copied, and which can be skiped. The expensive way is to perform a checksum, but most sync tools rely on the creation or modified date unless told otherwise. Now say Alice and Bob have the same copy of file F, Bob modifies it first which gets stored at timestamp T, then Alice modifies her copy at time T+1. Bob syncs his files on a filer, its timestamp gets reset to now, which is say T+2. Then Alice does the same, but her file does not get copied, since the remote timestamp T+2 is newer than her local timestamp T+1.
  - account42 1y ago
    You do you expect the ACL to be copied but not the owner? They are different abstractions of the same thing.

bayindirh 2y ago

As a counterpoint, many daemons or programs (e.g.: sshd, ssh, slurm, munge to name a few) expect their files to have specific users, groups and modes for security and behavioral guarantees, and flat out refuse to run if these requirements are not met. When installing these things from archives or moving/distributing relevant files to large fleets, I expect the file contents and all metadata incl. datestamps to be carried the way I want, because all of that data is useful for me and the application which uses the file. If the user doing the copying has no right to copy the file exactly, I either expect a loud warning or an error depending on the situation.

op00to 2y ago
Should the SELinux context of a file always be copied from the source when moving or copying it? Or should it typically inherit the context defined by policy for the destination directory structure? For example, copying a file from a user's home directory (perhaps user_home_t) into /var/www/html/ usually requires it to get the httpd_sys_content_t context (or similar) to be served by the webserver correctly and securely. Blindly copying the original user_home_t context would likely prevent the webserver from accessing the file. Doesn't this suggest that some metadata, specifically the SELinux context, often shouldn't be copied verbatim from the source but rather be determined by the destination and the system's security policy?
- bayindirh 2y ago
  What if the tool accessing the file is malicious, and can copy the file, but can't change the context of the said file? SELinux shall be strict on its behavior even if it's a detriment to user convenience. SELinux contexts shall be sticky, and needs to be manually (re)set after copying. This is the default behavior, BTW. SELinux contexts are not (re)set during copy operations in most cases, from my experience. You need to change/fix the context manually.
  - op00to 2y ago
    I think when I cp a file it takes on the context of the directory or whatever the default context for that path is supposed to be, and when I mv, it retains the original context.

bmacho 2y ago

> But what you're referring to here are the attributes that the file system stores about the file, not the file itself. Yes. Sometimes you need that additional information too. And if you do, then rsync is your tool. If you only need the data stored in the file, then drag & drop suffices.

mannyv 2y ago

The executed bit is an attribute that the FS stores about the file, and isn't technically part of the file itself. Strip all the execute attributes out of your *nix system and see what happens.