I realized that BigFix action script “copy” command changes file permissions on UNIX/linux platforms.
It only keeps “User” permissions, and changes “Group” and “Others” permissions to 0.
For example, copying a file having 644 permissions (rw-r–r--) withing an action script using “copy” command creates a file with 600 permissions (rw-------).
“move” commands doesn’t change permissions.
Does anyone knows why “copy” command changes permissions?
This behavior is the same on Windows, and, I believe, mirrors the behavior of the shell commands “cp/copy” and “mv/move”, or at least the syscalls behind those commands.
“Copy” creates an entirely new file, and the new file inherits the default permissions of the folder in which it is created (based on umask on UNIX-like operating systems or folder ACLs on Windows); while “move” only changes the directory link/relocates inode for an existing file, and retains the permissions and attributes of the original file (which in this case was previously created with the very restrictive directory permissions of the __BESData folder).
There are some edge-cases to “move” whose behavior I can’t recall at the moment - for instance when the target is on a different drive or different filesystem it might behave like Copy? But I don’t recall the detail there.
In most cases, if a user is going to need to interact with the generated file (such as an ‘override wait’ command to execute a script in User context), we would want to be sure to use “copy” rather than “move”.