cp -p preserves many attributes at the copied file, including the "last modified" timestamp.
This works across files on disk, but not when i copy to a windows file mounted via smb.
Strange enough, from a program i can do a copy with correct timestamp setting!
e.g. in a Perl script using utime. Why does cp -p not work here? Is it a bug, or
am i missing something?
cheers, Neo.
MacBook Air, OS X Mavericks (10.9.5)
I'm not certain this is correct, but I don't see how anything could control the desires of the destination file system. If the destination file system doesn't want to preserve the timestamp on a file on its file system, there isn't anything you can do from the sender side.
Modern versions of cp try to preserve all attributes, including resource files and Finder metadata, on foreign file systems. Check from somewhere other than your Mac and see if you are creating lots of ._ files for each file you copy. Since those are technically new files, they have the current timestamp. Then, when OS X tries to consolidate the foreign file system files, it sees the newer timestamp on the metadata file.
Let me follow up:
It is not a feature (or "desire") of the smb filesystem, because I can preserve the modified timestamp when i copy via the emacs copy function, or via a perl script. Only cp -p does not do what it should. Of course, other features that should be preserved with the -p option do not exist on the foreign file system (like ugo-permissions) and therefore cannot be preserved. But i should expect that those features that do exist are preserved. So I think it is a bug of the cp command!
This bug is still present in OS 10.11.5. I just verified it on an NTFS partition shared by a Windows 7 machine.
Similar behavior: the cp -a command fails to copy the modification time, but other methods, e.g. Python shutil.copy2, work.
An interesting mal-feature: the modification time is initially set correctly but later reverts. E.g.,
$ cat cpTest
#!/usr/bin/env bash
cp -a resort.py resort2.py
for i in {0..60}; do
echo After $i seconds ...
ls -lT resort*
echo
sleep 1
done
$ ls -l resort*
-rwx------ 1 Billy staff 2423 Feb 9 20:52 resort.py
$./cpTest
After 0 seconds ...
-rwx------ 1 Billy staff 2423 Feb 9 20:52:09 2016 resort.py
-rwx------ 1 Billy staff 2423 Feb 9 20:52:09 2016 resort2.py
After 1 seconds ...
-rwx------ 1 Billy staff 2423 Feb 9 20:52:09 2016 resort.py
-rwx------ 1 Billy staff 2423 Feb 9 20:52:09 2016 resort2.py
After 2 seconds ...
-rwx------ 1 Billy staff 2423 Feb 9 20:52:09 2016 resort.py
-rwx------ 1 Billy staff 2423 Feb 9 20:52:09 2016 resort2.py
...
After 28 seconds ...
-rwx------ 1 Billy staff 2423 Feb 9 20:52:09 2016 resort.py
-rwx------ 1 Billy staff 2423 Feb 9 20:52:09 2016 resort2.py
After 29 seconds ...
-rwx------ 1 Billy staff 2423 Feb 9 20:52:09 2016 resort.py
-rwx------ 1 Billy staff 2423 Jun 5 20:01:18 2016 resort2.py
Is that not perverse or what?
BTW, I also tried it on the same share mounted on an Ubuntu 12.04 system. No issues. Moreover, Ubuntu copied the whole timestamp, instead of truncating the deci-microseconds, as OS X does.
cp to smb does not prserve timestamp
