I have my primary audio store on a Windows server. I have nightly sync jobs that push any updates to those files to my NUC ROCK server (attached USB drive). Sync job uses RoboCopy (/MIR /Z options)
I recently noticed that each time my syncing job runs, its overwriting ALL the files. In troubleshooting, I noticed something very odd. If I watch the folder being copied, for each file I see its mod date switch from whatever it should be, to a date in 1980, and then back to whatever it should be.
Its almost like for some reason the mod date gets changed just before RoboCopy looks at it, so RoboCopy copies the file over. I’ve never seen this on any other RoboCopy job so seems like it has something to do with ROCK. Any ideas?
have you rebooted the rock ?
Yup, multiple times.
My theory is that when RoboCopy touches the file, ROCK’s indexer is changing its mod date, causing RoboCopy to then overwrite it…
Ah yes. i think you are supposed to suspend the monitoring then copy then resume.
Low power from the bios battery?
I think I solved it - in case any ones else hits it: seems that the source (NTFS) and the destination (exFAT, or at least, the way that SMB or whatever they are using presents the destination) have different mod date granularity, causing RoboCopy to always think the file dates are different.
The solution is to add the /FFT to the robocopy script, which forces FAT granularity. The 1980 mod date I think is just what gets shown when the file is actually copying.
/FFT uses fat file timing instead of NTFS. This means the granularity is a > bit less precise. For across-network share operations this seems to be much more reliable - just don’t rely on the file timings to be completely precise to the second.
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.