![]() ![]() Robocopy does not copy exclusively locked files. Later versions include multi-threading and un-buffered I/O support. The utility provides extensive options that include copying security, backup API support, retry capabilities, and logging. The Robocopy (Robust File Copy) command-line utility is included with Windows Server. The Robocopy method is one of several pre-seeding methods for an overview, see Step 1: pre-seed files for DFS Replication. By pre-seeding files before you set up DFS Replication, add a new replication partner, or replace a server, you can speed up initial synchronization and enable cloning of the DFS Replication database in Windows Server 2012 R2. This topic explains how to use the command-line tool, Robocopy.exe, to pre-seed files when setting up replication for Distributed File System (DFS) Replication (also known as DFSR or DFS-R) in Windows Server. The expected behavior is robocopy once, but actual behavior is older and copy over and over.Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 Robocopy.exe "C:\Users\piete\Downloads\ttk" "\\UNRAID\Transfer\test" /mir /fft Try it out using the attached 7z file, extract to NTFS. I set them last night, this AM they were back to 1980 dates. I am not certain, but it also looked as if the timestamps I set were changed during the night, i.e. I did find various bug reports of CIFS not correctly preserving times, and that in Linux there is no created time, just changed (attributes), modified (contents), and accessed times. To confirm I wrote a native C app to do the same, same behavior. NET Core app to set the destination file timestamps to the source timestamps, does not work. The files that will always be "older", are files that have a created date, but not a modified or accessed, interpreted as " 12:00:00 AM" UTC. I don't think this is a permission problem, this is a file timestamp problem. I am concerned that my data copy is not accurate.Īny known problems with robocopy or differences between windows handling of names and unraid handling of names of SMB? Is this an unraid / SMB timestamp problem? When I looked at two files where the timestamps were wrong, I can see that the unraid timestamps is not the same as that of the W2K16 server. It is as if the file timestamps are even less granular then /FFT, or the file timestamps get changed by unraid after copy, invalidating the previous operation. Same as the directory that does not delete, I can run robocopy clean, run it again, and it will copy a bunch of files again. I am using the fat file time /FFT option to work around the lack of nanosecond granularity on EXT4/XFS vs. When I rerun robocopy, I will get the hundreds of files being reported as older on unraid, when those files have never been changed. See the attached image, the directory on Unraid is there, but there are also directories that are not syncing, the "LocalState." directory, note the double dots on the end of the folder name. While "rd \\Unraid\backup\Profiles\SZ170R6V2\piete\AppData\Local\Packages\_cw5n1h2txyewy\L8EVMY~1\" does delete the folder. I can run robocopy over and over, and that same directory will never delete. *EXTRA Dir -1 \\Unraid\backup\Profiles\SZ170R6V2\piete\AppData\Local\Packages\_cw5n1h2txyewy\L8EVMY~1\ Options : *.* /FFT /S /E /DCOPY:DA /COPY:DAT /PURGE /MIR /MT:8 /R:1 /W:1 I noticed a problem where it appears that the files and folders are not being correctly synced.Ĭ:\Users\Administrator\Desktop>robocopy.exe D:\Backup \\Unraid\backup /mir /r:1 /w:1 /fft /mt I am copying files from my W2K16 server to Unraid using robocopy over SMB. ![]()
0 Comments
Leave a Reply. |