[Samba] Robocopy, archive bit and ACLs

[Jochen Eggemann]

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
>