[Samba] Robocopy, archive bit and ACLs
Jochen.Eggemann at nw-fva.de
Wed Dec 12 06:46:09 UTC 2018
use /FFT it assumes a 2 second granularity for files
Am 09.12.18 um 03:35 schrieb Jerome Charaoui via samba:
> 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?
> -- Jerome
More information about the samba