Incorrect create-time when using Rsync from mac, but cp -p works

benze

Dabbler
Joined
Dec 30, 2013
Messages
17
I'm running into a strange issue with timestamps when trying to copy/backup files from my Mac to a shared drive on TrueNas.

My drive is defined in TrueNAS as a Home Share and mounted in MacOS via the Finder:

Code:
> mount
//eric@truenas._smb._tcp.local/eric on /Volumes/eric (smbfs, nodev, nosuid, mounted by via)


However, when I attempt to rsync, I get the creation date in my mount wrong:
Code:

macos > ls -lt  20180210_120110_001.jpg   
-rw-r--r--  1 via  staff  723237  7 Jun  2018 20180210_120110_001.jpg

macos > rsync -avztUN 20180210_120110_001.jpg /Volumes/eric/Pictures/Galaxy\ S21/2023-05-19/DCIM/Camera
sending incremental file list
20180210_120110_001.jpg

sent 663,066 bytes  received 35 bytes  1,326,202.00 bytes/sec
total size is 723,237  speedup is 1.09



macos > ls -lt  /Volumes/eric/Pictures/Galaxy\ S21/2023-05-19/DCIM/Camera  
total 1326
-rwx------  1 via  staff  723237 23 May  2023 20180210_120110_001.jpg


As you can see using rsync, the created timestamp is incorrect in the Volume mount (the TrueNAS mount)


However, this is the strange thing, if I do the same thing with cp -P, the timestamp is maintained:





Code:
macos >ls -lt  20180210_120110_002.jpg                                                                                             
-rw-r--r--  1 via  staff  687066  7 Jun  2018 20180210_120110_002.jpg

macos >cp -p 20180210_120110_002.jpg /Volumes/eric/Pictures/Galaxy\ S21/2023-05-19/DCIM/Camera                                     

macos >ls -lt  /Volumes/eric/Pictures/Galaxy\ S21/2023-05-19/DCIM/Camera                                                           
total 2583
-rwx------  1 via  staff  723237 23 May 09:17 20180210_120110_001.jpg
-rwx------  1 via  staff  687066  7 Jun  2018 20180210_120110_002.jpg



As you can see, the second file (_002.jpg) has the correct timestamp copied, whereas the first one does not.

Any ideas what might be the issue or how I can debug this timestamp issue?

Thanks,

Eric
 
Top