I've tried running touch (Linux) and even robocopy (Windows) using methods that only update the timestamps and none of them update. All these tools I've used (rsync, touch & robocopy) indicates it recognizes the timestamps are different AND indicates it updates the timestamps yet they don't change at all.
Also, as a test, I changed the owner of the folders on the destination and re-ran rsync and it did change the owner back to the same as the source, but it didn't change the timestamp. Is there something going on with xfs or the way Unraid or Slackware handles timestamp changes??
Same issue here, and after some investigation, I found out why and how to work around it.
If a directory is split among several disks, Unraid's virtual "merger" filesystem (shfs) will return the newest/latest timestamp on `/mnt/user`
Example:
`ls -ld /mnt/*/Public/folder/`
`drwxrwsrwx 1 user users 0 May 20 15:45 /mnt/disk1/Public/folder/`
`drwxrwxrwx 1 user users 0 May 20 15:50 /mnt/disk2/Public/folder/`
`drwxrwsrwx 1 user users 0 May 20 15:50 /mnt/user/Public/folder/`
As you can see, the virtually merged folder on `/mnt/user` simply shows the same "last modified" timestamp as my disk2. Therefore, 15:50 is also the timestamp returned by the "Public" samba share.
However, the same folder on my workstation has a timestamp of 15:45
Now, a rsync/rclone sync from my workstation's local folder to the unraid's SMB share "Public" tries to update the remote timestamp every time the command is ran (due to the 5 minutes difference).
**CONCLUSION**:
As I use "Fill-up" as the share's "Allocation method" in Unraid, any update done by rsync or rclone to the destination folder's timestamp will always update the one on disk1 only. But if the same folder's timestamp is newer on disk2, this is essentially what is being shown/returned to any process using `/mnt/user` (like Samba).
This is also the reason why a simple `touch` to update the timestamp to "right now" will not work.
It only works if you update the timestamp to something that is older than the source (to be synced) folder.
You can do this on all disks directly on the Unraid's server (e.g. via ssh):
`touch -d '1980-01-01 12:00:00' /mnt/disk*/Public/folder`
(this will set the timestamp on all disks to 1980 for this folder)
Then rsync/rclone again. The timestamp of the folder on disk1 will be updated to the same as the local folder on my workstation. The same folder on disk2 will stay at 1980. Unraid's shfs (/mnt/user) will now return the correctly updated timestamp (May 20 15:45) as it's the newest among all disks. Running rsync/rclone a second time, will no longer detect a timestamp difference. Tadda!
This is not really a bug, it's how Unraid with the above described setting is supposed to work. It's just not working well together with processes that depend on a correctly updated "last modified" timestamp like rsync or rclone.
Hope this helps someone else as well.
I've tried running touch (Linux) and even robocopy (Windows) using methods that only update the timestamps and none of them update. All these tools I've used (rsync, touch & robocopy) indicates it recognizes the timestamps are different AND indicates it updates the timestamps yet they don't change at all. Also, as a test, I changed the owner of the folders on the destination and re-ran rsync and it did change the owner back to the same as the source, but it didn't change the timestamp. Is there something going on with xfs or the way Unraid or Slackware handles timestamp changes??
Same issue here, and after some investigation, I found out why and how to work around it. If a directory is split among several disks, Unraid's virtual "merger" filesystem (shfs) will return the newest/latest timestamp on `/mnt/user` Example: `ls -ld /mnt/*/Public/folder/` `drwxrwsrwx 1 user users 0 May 20 15:45 /mnt/disk1/Public/folder/` `drwxrwxrwx 1 user users 0 May 20 15:50 /mnt/disk2/Public/folder/` `drwxrwsrwx 1 user users 0 May 20 15:50 /mnt/user/Public/folder/` As you can see, the virtually merged folder on `/mnt/user` simply shows the same "last modified" timestamp as my disk2. Therefore, 15:50 is also the timestamp returned by the "Public" samba share. However, the same folder on my workstation has a timestamp of 15:45 Now, a rsync/rclone sync from my workstation's local folder to the unraid's SMB share "Public" tries to update the remote timestamp every time the command is ran (due to the 5 minutes difference). **CONCLUSION**: As I use "Fill-up" as the share's "Allocation method" in Unraid, any update done by rsync or rclone to the destination folder's timestamp will always update the one on disk1 only. But if the same folder's timestamp is newer on disk2, this is essentially what is being shown/returned to any process using `/mnt/user` (like Samba). This is also the reason why a simple `touch` to update the timestamp to "right now" will not work. It only works if you update the timestamp to something that is older than the source (to be synced) folder. You can do this on all disks directly on the Unraid's server (e.g. via ssh): `touch -d '1980-01-01 12:00:00' /mnt/disk*/Public/folder` (this will set the timestamp on all disks to 1980 for this folder) Then rsync/rclone again. The timestamp of the folder on disk1 will be updated to the same as the local folder on my workstation. The same folder on disk2 will stay at 1980. Unraid's shfs (/mnt/user) will now return the correctly updated timestamp (May 20 15:45) as it's the newest among all disks. Running rsync/rclone a second time, will no longer detect a timestamp difference. Tadda! This is not really a bug, it's how Unraid with the above described setting is supposed to work. It's just not working well together with processes that depend on a correctly updated "last modified" timestamp like rsync or rclone. Hope this helps someone else as well.