Re: [Samba] Robocopy, archive bit and ACLs
- Date: Wed, 12 Dec 2018 07:46:09 +0100
- From: Jochen Eggemann via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] Robocopy, archive bit and ACLs
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
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?
To unsubscribe from this list go to the following URL and read the