Hello, I'm attempting to set up a daily Robocopy task on a Windows Server 2016 to duplicate a large directory tree -- including data, timestamps and ACLs -- to a Samba 4.5.12 server. This is my Robocopy command: Robocopy.exe C:\source \\foo\bar /XA:SH /XJ /MIR /NODCOPY /COPY:DTSO /A+:A /ZB I noticed that for a significant number of files, Robocopy will systematically identify them as modified even though no aspect of them will have changed in any way. After much trial and error, I tracked the cause down to the archive bit. If the archive bit is set the same way on the source and destination (either both on or both off), Robocopy will detect the file as "Modified" and count it toward "Copied" files. If the bit differs, regardless of which way, this does not happen. I also noticed that if I remove both "SO" flags from the /COPY: argument, the issue goes away. My current workaround is to use /A+:A, making sure the copied file gets its archive bit set and run "attrib -a C:\source\*.* /s /d" before Robocopy runs. This is suboptimal because a) it requires me to modify the (big) source file tree which I'd rather not and b) I really don't *care* about the archive bit. Now, I understand the issue is probably due to some quirkiness (to put it mildly...) of Robocopy, but alas it's not like we could just go ahead and fix the darn thing. Have other Samba users encountered a similar problem? Did you find a better way to work around it? Is there some way I could hack Samba to report the archive bit in a manner that would keep Robocopy satisfied? And lastly, if I was to give up on Robocopy as a Windows backup tool, what would one use today as a solid alternative? Thanks, -- Jerome
On Sat, Dec 08, 2018 at 09:35:33PM -0500, Jerome Charaoui via samba wrote:> Hello, > > I'm attempting to set up a daily Robocopy task on a Windows Server 2016 > to duplicate a large directory tree -- including data, timestamps and > ACLs -- to a Samba 4.5.12 server. > > This is my Robocopy command: > Robocopy.exe C:\source \\foo\bar /XA:SH /XJ /MIR /NODCOPY /COPY:DTSO > /A+:A /ZB > > I noticed that for a significant number of files, Robocopy will > systematically identify them as modified even though no aspect of them > will have changed in any way. > > After much trial and error, I tracked the cause down to the archive bit. > If the archive bit is set the same way on the source and destination > (either both on or both off), Robocopy will detect the file as > "Modified" and count it toward "Copied" files. If the bit differs, > regardless of which way, this does not happen. I also noticed that if I > remove both "SO" flags from the /COPY: argument, the issue goes away.The 'A' bit is set whenever a file has been modified, meaning it needs backing up. So I'm guessing if Robocopy sees the 'A' bit on a source file it knows it should back it up. If the 'A' bit differs then I'm assuming that Robocopy just thinks that means the file metadata is different and should also copy.
Hi Jerome use /FFT it assumes a 2 second granularity for files Regards Jochen Am 09.12.18 um 03:35 schrieb Jerome Charaoui via samba:> Hello, > > I'm attempting to set up a daily Robocopy task on a Windows Server 2016 > to duplicate a large directory tree -- including data, timestamps and > ACLs -- to a Samba 4.5.12 server. > > This is my Robocopy command: > Robocopy.exe C:\source \\foo\bar /XA:SH /XJ /MIR /NODCOPY /COPY:DTSO > /A+:A /ZB > > I noticed that for a significant number of files, Robocopy will > systematically identify them as modified even though no aspect of them > will have changed in any way. > > After much trial and error, I tracked the cause down to the archive bit. > If the archive bit is set the same way on the source and destination > (either both on or both off), Robocopy will detect the file as > "Modified" and count it toward "Copied" files. If the bit differs, > regardless of which way, this does not happen. I also noticed that if I > remove both "SO" flags from the /COPY: argument, the issue goes away. > > My current workaround is to use /A+:A, making sure the copied file gets > its archive bit set and run "attrib -a C:\source\*.* /s /d" before > Robocopy runs. This is suboptimal because a) it requires me to modify > the (big) source file tree which I'd rather not and b) I really don't > *care* about the archive bit. > > Now, I understand the issue is probably due to some quirkiness (to put > it mildly...) of Robocopy, but alas it's not like we could just go ahead > and fix the darn thing. > > Have other Samba users encountered a similar problem? Did you find a > better way to work around it? Is there some way I could hack Samba to > report the archive bit in a manner that would keep Robocopy satisfied? > And lastly, if I was to give up on Robocopy as a Windows backup tool, > what would one use today as a solid alternative? > > > Thanks, > > -- Jerome >