Use robocopy to mirror source but ignore timestamp
After a succesfull copy in explorer the timestamps are equal but somehow Robocopy copies the same file the next time it runs and claims source file is newer. Seems to be a problem with the smb version on the nas.
Add the /FFT
switch with Robocopy:
ROBOCOPY /MIR /FFT <source> <dest>
/FFT : Assume FAT File Times (2-second date/time granularity).
/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.
Related videos on Youtube
Jürgen Steinblock
Updated on September 18, 2022Comments
-
Jürgen Steinblock over 1 year
I want to backup a folder to a share on a linux nas with robocopy.
I use the commandline
robocopy /mir <source> <dest>
After a succesfull copy in explorer the timestamps are equal but somehow robocopy copies the same file the next time it runs and claims source file is newer. Seems to be a problem with the smb version on the nas.
Now I can use
/xn
switch to prevent the file copy but that will also prevent the file from being copied the next time I run the same job.So my question is: How do I use robocopy to ignore the timestamp but only copy a file if the file size changed (I know this would not be a 100% solution) but since I want to backup office documents and pictures, this would be OK for me.
-
Admin over 8 yearsYou already know this idea has issues - content can change without affecting file size. Also, the modified date can be altered by things like AV. I wrote a back up program (to back up my Windows files to my Linux NAS too) because I ran into these problems using
XCOPY
andRobocopy
. You are better to get the HASH of the file and then compare them but this isn't do-able in robocopy. Since robocopy isn't the right tool (IMO), why not use other software? What actually is the issue? If you're only copying office documents and pictures, I assume the time it takes isn't really a problem?
-
-
Jürgen Steinblock over 8 yearsThat did the trick. Thumbs up