There is a difference between copy and cp. From File::Copy:
... as of version 2.15, "cp" will preserve the source file's permission bits like the shell utility cp(1) would do, while "copy" uses the default permissions for the target file (which may depend on the process' "umask", file ownership, inherited ACLs, etc.). ...
In summary:
copy: copy file with default permissions
cp: copy file preserving permissions
syscopy: not actually sure what it does (doesn't preserve owner or permissions in Linux)
Being a Linux user, I'm not actually sure what filesystem oddness syscopy is trying to address. It seems that in Linux, "cp" is the best option. It may be that syscopy is best on other OSes (assuming what you really want is a true copy of all file properties).
Update: Fixed some descriptions after testing a bit.
| [reply] [d/l] [select] |
Makes no difference and "cp" isn't documented
I've never had a problem in over a decade, so I won't UTSL to try to decipher what rurban is talking about -- outburst without substance
| [reply] |
outburst without substance?
if you have no idea what you are talking about, don't do it. if you never had a problem you are probably not deep enough into it, and you obviously never looked into the differences and accepted the wrong defaults.
copy was the simple idea of perl IO copying, block per block, allowing handles, but it did not care about OS specific settings,
like preserving permissions or ownership. This was a big issue over and over and p5p never cared.
This was fixed finally a few releases ago (2.15 exactly), but there are still older perls around which use the old simple copy, loosing file attributes.
The problem is mostly in os-compat Makefiles, which does use ExtUtils::Command cp for copying files, i.e. executables or shared libs, which loose there x bit after that treatment.
syscopy uses the system provided syscopy and preserves attribs on most OS, and cp uses the cp(1) utility with filenames, if available.
| [reply] |