robocopy always copies files

[bblades262]

Hello all,
My apologies if i am posting on a topic already answered but I searched and I couldnt find anything. For some reason when i robocopy from my primary backup server to my FreeNAS box the file timestamp changes to 1/1/1980 for every file checked, as its checked. In effect all data is re-copied on every operation. has anyone seen this before? Does anyone know how to stop this behavior?

below is the string i use to kick off the copy:

Code:

robocopy "C:\Backup" "\\FREENAS\Backup" /R:3 /W:3 /MIR /NP /Z /LOG+:C:\Logs\Backup.log 2>&1

 

[Yell]

Does robocopy use accesstime?

if so look at the mount options (noatime)
http://www.freebsd.org/cgi/man.cgi?query=mount&sektion=8
or the pooloptions
http://prefetch.net/blog/index.php/...access-time-atime-updates-on-zfs-file-system/

 

[bblades262]

Does robocopy use accesstime?

if so look at the mount options (noatime)
http://www.freebsd.org/cgi/man.cgi?query=mount&sektion=8
or the pooloptions
http://prefetch.net/blog/index.php/...access-time-atime-updates-on-zfs-file-system/

I do have atime disabled on FreeNAS, as per the sticky shares walkthrough. I did some research into robocopy, and I found that it sets the timestamp on the destination file to 1/1/80 during the copy, then resets it to the correct timestamp after the copy completes. Also, after my post I added the /FFT switch to the robocopy command and now it seems to be skipping over files with the same timestamp at source and destination.

 

[stualden]

I know this is an old thread, but since I came up against the same problem I wanted to find out what was causing it. I found the answer, so I thought it best to put it here (even though it triggers another question...).

When you copy files from an NTFS volume to a FreeNAS CIFS share, it appears that the "date modified" timestamp (stored as a number of 100-nanosecond "ticks") loses its right-most digit. Of course the timestamp looks identical down to the second, but if you get down to the full precision you can see the difference. For example, if the original is C:\file.txt and the copy is over on Z:, then using Windows Powershell you can see

PS C:\> (dir file.txt).lastwritetime.ticks
633802525401258876

PS C:\> (dir Z:\file.txt).lastwritetime.ticks
633802525401258870

Thus Robocopy, which by default is performing a copy whenever the source file is "different" (older, newer, or a different size), will generally see the source file as "Newer" and launch another copy even though it is unecessary. The /FFT switch (ignore timestamp differences smaller than the FAT granularity of 2 seconds) therefore solves the problem (albeit in a pretty brute-force fashion).

So now my question - is this a ZFS issue, or a Samba issue, or something else? Adding one more digit of timestamp granularity seems like a rational request, but I have no sense of whether it's a reasonable request.

EDIT: If I create a file on a dataset from the shell and then check its timestamp from Windows, the last digit of lastwritetime.ticks is always 0. So it appears that it is not a copying problem, per se, but rather a granularity problem (maybe ZFS timestamps only go down to milliseconds?) or perhaps a Samba "reporting" problem. Could someone please shed some light on this?