Talk:Robocopy

Similar utilities

I've added a 'similar utilities' section. I know there's lots; I just added one of my favourites. I consider this would help those looking for a backup/copying tool. peterl 04:59, 1 March 2007 (UTC)

List of command line switches

This is absurd. Wikipedia is not every software product's manual.

[Why absurd? This information is helping me save a lot of data off a crashed Vista computer right now.] —Preceding unsigned comment added by 24.231.249.80 (talk) 05:01, 21 September 2007 (UTC)

Maybe this belongs in Wikibooks. --NuShrike 18:57, 8 May 2007 (UTC)

For command line tools, I think the list is as good a way as any to describe its functionality. — Preceding unsigned comment added by 70.168.130.3 (talk) 17:44, 14 June 2007

I agree that this information is suitable for Wikipedia. The tool is very notable since it is an inclusion of Windows Vista, and is just as important as describing User Account Control. The list has grown command-by-command, put there by people who found a particular Robocopy command useful. I don't think anybody has simply duplicated the documentation verbatim. The fact is, Robocopy is the only Microsoft-provided tool that does many of these reliably. I doubt anybody provided any of this information if they didn't consider it extremely useful to others. It is no different than the Swiss army knife article describing each of the tools contained therein. Reswobslc 06:01, 22 September 2007 (UTC)

It's also worth noting that the history of productive anonymous-IP edits from a relatively high number of unique IP addresses is a good indicator that this article has been found useful by a large number of people finding this article on Wikipedia while searching the Web. Reswobslc 14:19, 6 October 2007 (UTC)

The question is not whether the content is useful. The question is whether it is appropriate content for a Wikipedia article. It probably is not. A larger concern is that the section is copied from Robocopy /? output. I have marked it as such. —Preceding unsigned comment added by Kvng (talk • contribs) 15:13, 23 February 2010 (UTC)

Another vote for useful. And I believe the question of useful is relevant. After all, of what use is a Wiki that does not contain useful information? I came to this site SPECIFICALLY to get detailed information on robocopy, which I found. So, to whomever posted the list of command-line switches, thank you. —Preceding unsigned comment added by 216.112.116.6 (talk) 04:31, 3 March 2010 (UTC)

Where is the list of command Line Switches? I have been using this page for a long time as it had a superb list of the switches. now I find they have been removed because it made the page into a HOWTO! Odd. I see the Dos Commands page still has a list of DOS Commands: http://en.wikipedia.org/wiki/List_of_DOS_commands —Preceding unsigned comment added by 217.154.147.226 (talk) 14:21, 17 May 2010 (UTC)

As a compromise, maybe someone can create a List_of_ROBOCOPY_commands page and link to it from the Robocopy page? 99.153.184.77 (talk) 05:19, 13 June 2013 (UTC)

Speed and performance.

A guy at my office says robocopy is faster than the copy accessible through windows explorer. Any word on this?

Reply: Yep, it appears to be about 2.5x faster in some cases.

"Proformat" is not a word (yet).

http://boulter.com/blog/2004/08/19/performant-is-not-a-word/ http://weblogs.asp.net/jgalloway/archive/2007/05/10/performant-isn-t-a-word.aspx

199.64.0.252 (talk) 21:47, 16 June 2008 (UTC)

Wrong on two counts - (a) it is in dictionaries (meaning "performer") e.g. www.dictionary.com; and (b) whether or not something is a word is not decided by whether or not it is present in dictionaries ... if a place wasn't on a map would you say it wasn't a place? The links provided above claim over 12,000 documented uses of this "non-word". —Preceding unsigned comment added by 94.193.98.124 (talk) 16:25, 23 November 2009 (UTC)

ACLs

The article seems to say that robocopy copies ACLs by default. But the robocopy help says:

/COPY:copyflag[s] :: what to COPY (default is /COPY:DAT).
                     (copyflags : D=Data, A=Attributes, T=Timestamps).
                     (S=Security=NTFS ACLs, O=Owner info, U=aUditing info).

which means that ACLs aren't default.-06:44, 30 August 2007 (UTC)~

Changed article to reflect that this is correct. Reswobslc 05:59, 22 September 2007 (UTC)

Suggested Corrections to beyond the built-in Windows COPY and XCOPY commands section

"Ability to copy entire subdirectories": 
This should be removed as both COPY and XCOPY can easily be used to do this

"Ability to copy large numbers of files that would otherwise crash the built-in XCOPY utility.":
"Large numbers" should to be quantified by the author. In my experience, I've used XCOPY on Windows 2000 with entire volumes
containing over 100,000 files.

I found COPY and XCOPY both failed to copy files larger than 4bg in (windows server 2003). ~~ —Preceding unsigned comment added by 213.199.128.155 (talk) 11:42, 7 January 2008 (UTC)

The number is no clear limit. It depends on the command switches you use with xcopy. In my environment I get always an "Out of memory" error with about 50.000 files when I use the /D switch. Robocopy has no problems with that. So this is a main reason for many people to use it instead of xcopy.--80.139.250.233 (talk) 21:46, 1 September 2010 (UTC)

213.199.128.155: Large files is different to large numbers of files. Files over 4Gb seems a FAT problem, not xcopy itself.

"Large numbers of files" - there seems to be a common perception xcopy's 'insufficent memory' error refers to the number of files being copied, when its actually complaining about file paths longer than 259 characters. This may be what's being referred to by the original author. —Preceding unsigned comment added by 122.110.6.6 (talk) 05:43, 16 August 2008 (UTC)

copy commands

Unix/*nix programs (Also sometimes used in Windows versions)

• cp -- copy files; can concatenate files
• cpio -- copy an entire directory structure from one place to another
• cat -- concatenate and display files
• dd -- copy streams, files, or devices in whole or part
• head -- display/copy the first part of a file
• tail -- display/copy the last part of a file

DOS/Windows programs (Seldom used in *nix versions)

• COPY -- copy files or sets of files, binary or text mode, can concatenate files
• XCOPY -- eXtended version of COPY, for copying file structures
• XXCOPY -- further extended commercial program
• ROBOCOPY -- further extended version, included in Vista, Also available a part of the optional Windows 2000, Windows 2003 and windows XP resource toolkits.

Other specialized programs are used to split large files into pieces and then put the pieces back together.

Remote executing? (rsync -e) —Preceding unsigned comment added by Abonino (talk • contribs) 07:15, 19 March 2009 (UTC)

There are no good standard programs to extract an arbitrary piece of a file into another file. dd can be used, but requires setting blocksize to 1, which is very inefficient. In Windows, the obscure program CPART can be used.

grep and awk are powerful *nix programs for looking for patterns in a file. -69.87.200.198 00:34, 17 October 2007 (UTC)

69.87.200.198 emitted "In Windows, the obscure program CPART can be used." I'd say it is obscure as it's not part of windows. Marc Kupper (talk) (contribs) 17:25, 5 September 2008 (UTC)

I wouldn't classify robocopy as just a file copying program like tail or cp. It is more of a data center admin tool. It solves more complex problems, like keeping two folder trees synchronized, backing up changes, checkpointing and restarting its operation, etc. It's also one of the few programs that does these things correctly and robustly. DonPMitchell (talk) 01:54, 23 February 2010 (UTC)

Precision of Timestamps copied?

I'm afraid I can't find any documentation on the precision of timestamps that Robocopy preserves. In particular, it would be nice to know whether Robocopy only preserves the Modified time, or the Created and Last Accessed time as well (which most programs do not). Additionally, does Robocopy preserve the Created timestamp of a directory (folder)? And further still, I understand that some of these timestamps may include milliseconds--are these also preserved?

To date, I have yet to find a copy/move/sync software that does all of the above. Rather, the only program that comes close is WinRAR with its ability to preserve Modified, Created, Last Accessed and Folder timestamps. Agvulpine (talk) 07:03, 28 December 2007 (UTC)

I just tested it, and it looks to me like it preserves those values (I am using version "XP010"). I robocopied some data and it preserved the "created" and "modified" dates, though, obviously, the "accessed" date shows today. --P shadoh (talk) 15:44, 3 July 2008 (UTC)

Agvulpine: I believe XXCOPY (commercial) can do all three timestamps, which is one of their main bragging points. —Preceding unsigned comment added by 207.47.61.234 (talk) 21:36, 28 March 2008 (UTC)

Robocopy GUI

Does anybody know how well the Robocopy GUI works with the Vista version of Robocopy, as it seems to have been made before Vista came out?

Also, having some version information here would be good. I seem to have three different versions on my computers.Jason404 (talk) 17:13, 4 June 2008 (UTC)

This article in its present form is against WP rules

See WP:NOTHOWTO for why. Wikipedia is not a user's manual. For very many good and well thought out reasons. If someone thinks the howto section here is useful, it can be moved to Wikibooks. -- Egil (talk) 17:39, 30 August 2008 (UTC)

I disagree with your assessment, for the following reasons.

1. This is not, and never was, a "howto". The content you've removed doesn't purport to guide or instruct anyone through the process of doing anything.

2. With Robocopy being a fundamental component of Windows, being the "best practice" built-in utility for copying and backing up files from command line scripts, I think you've underestimated its importance. I doubt you'd go over to COMMAND.COM wherein a list of MS-DOS commands can be found, and argue that the list constitutes a "howto" or a "manual" for the usage of MS-DOS. Nor would you go to C++ and argue that the article constitutes a "howto" on making a C++ program. Both of those have so much penetration and relevance to computing that a list of their commands and keywords is entirely appropriate. Further, the selection of command line options explained and represented have likely been chosen due to their usefulness, rather than this being a mere verbatim reproduction of the "user manual".

3. Look at the article's edit history. The sheer number of unique people editing the article ought to give you a glimpse into how many people consider the article "useful". The article is hardly the product of any person or small group of people.

Thanks Reswobslc (talk) 06:53, 1 September 2008 (UTC)

Sorry, but this discussion wrt to what Wikipedia is and is not was resolved long time ago, please see WP:NOTHOWTO for the current state. Listing all options and command line examples for a program is definitely a howto or an inctruction manual. The Internet is filled with places that has lots of useful information for lots of people. Wikipedia has always been very strict on building an encyclopedia. This is why it is such a success, and we need to make sure that we keep to those definitions to keep Wikipedia from being a big mess of anything. WikiHow is but one example of where manual and howto stuff can be placed, and this article could have a pointer to that howto. I'm not sure how long you have been aroundm but over the years, enormous amounts of howto style material has been removed from Wikipedia. This is a good thing, and the cleaning process must continue. Pointing to other articles that may need cleaning just shows the job is not done yet. -- Egil (talk) 09:27, 1 September 2008 (UTC)

I still disagree. I don't think you know what a "howto" is. I agree that Wikipedia is not a howto or an instruction manual, but in all your apologizing and attempts to explain to me why Wikipedia is such a "success", I don't think you got the memo - this is not, and never was, a howto. A howto is a document that instructs you through doing something, typically in a sequence of steps - and is usually titled as much, e.g. Wikipedia:How to fix cut-and-paste moves (the given example being acceptable due to being a Wikipedia howto in the Wikipedia namespace). This is an article about a utility called robocopy, not an article on how to copy files in Windows. Your suggestion that C++ and COMMAND.COM constitute further examples of "howto style" material that need to be "cleaned" is a little suspect - I would listen to some more community input before "cleaning" any more articles. Reswobslc (talk) 14:23, 1 September 2008 (UTC)

CD burning

It was my hope that I could use this utility to archive my files by burning them on dvd. I can't use simple windows gui copy because it doesn't preserve timestamps (or preserves only file/folder modification timestamp, not creation timestamp). But we must say it: robocopy.exe can't copy files to the standard Windows XP drag and drop cd burner. (by copying to D:\ folder, where D drive is a dvd burner). 80.244.146.197 (talk) 15:30, 16 November 2008 (UTC)

Fubar example

The example is fubar. Iowaseven (talk) 00:38, 15 February 2009 (UTC)

More details, please, on "Robocopy doesn't reliably copy short filenames."

Since this article is, in a roundabout sort of way, documentation of a M$ product, I suppose that statement is suitably vague, in the stylistic sense. :P However, for those of us who still insist on using robocopy (hey XXCOPY isn't perfect either, and at least this is free!) it would be nice to know what to look out for to avoid being burned by this deficiency. More details, please! What are the exact characteristics (length etc.) that make a filename risky? What behavior is exhibited when encountering one of these risky files, etc. Will the files at least show up in the log as skipped? Yes, I know this is not supposed to be the man page for robocopy, but a sentence or two just to give an indication of what to expect would be nice. TY. —Preceding unsigned comment added by 68.41.20.99 (talk) 19:06, 10 July 2009 (UTC)

I just had an experience of this. An original directory had one long file name and one short (two different files). And the short file name was a valid short file name of the long name. When this was copied to another disk, the file with the long name was copied first, and then the file with the short name was copied. When that last file (with the short name) was copied, Robocopy assumed that the long file name (which now already existed on the destination disk) was the same file, and thus it copied the file with the short name onto the existing file with the long name, overwriting it. The end result was that instead of having both files on the destination, only the file which originally had the short name existed there, but now with the long name. 8 July 2011 --- Magnus

See Long filename. I think by "short filenames", this refers to the 8.3 alternative filename assigned to each file by the operating system, visible by doing DIR /X at the command prompt. For example a file named "My Cookie Recipe.doc" might get a secondary filename of "MYCOOK~1.DOC" auto-generated, and a file named "My Cookie Dough.doc" might get "MYCOOK~2.DOC" since ~1 was already taken. The essence of the limitation is that although the normal filename will stay the same, the copy might get a different 8.3 filename with a different number (like ~1 if it goes into a folder where ~1 isn't taken). See Long filename. This limitation is only of interest to people using legacy DOS programs that only understand 8.3 filenames (and depend on them exclusively to find files) which nowadays is becoming overwhelmingly rare. Reswobslc (talk) 20:57, 12 July 2009 (UTC)

This is a problem that is inherently part of the operating system. Windows ALWAYS creates the 8.3 extensions at the time of copy by order in which the files are created, which is if you stand back and think about it the only real way it can as they are metadata to the new file, which are created on a first come first serve basis already.

That is to say if you have three files ABCDEFGHIJ01.txt ABCDEFGHIJ02.txt and ABCDEFGHIJ03.txt if you create the files (or copy or move them) in the order of ABCDEFGHIJ03.txt ABCDEFGHIJ01.txt ABCDEFGHIJ02.txt then they will have the following 8.3 versions

ABCDEFGHIJ01.txt ABCDEF~2.txt

ABCDEFGHIJ02.txt ABCDEF~3.txt

ABCDEFGHIJ03.txt ABCDEF~1.txt

You copy them in a different order the 8.3s will change again, it does not matter what utility you use. the only way to avoid this is to manually copy the files in the original order they were created.

The file meta data is transient and dependent on the order of file and directory creation for each individual location copied. This makes sense because I might have created ABCDEFGHIJ04.txt in another folder which would have assigned it short-file name ABCDEF~1.txt in that other folder, and then if I tried to copy it to the folder with my other three files two could not co-exist as ABCDEF~1.txt so the file is always assigned the next available 8.3 representation.

(I actually stumbled across this problem in 2000 as part of a windows 98/NT4 to 2000 Pro upgrade we were doing where shortcuts which relied on 8.3 file-names stopped working when files were copied back to the correct location!! XD

- Ben Personick

-- Taking Ownership, and fixing the spelling, of my original statement posted October 1st 2009 - user:QSquared -- 2010-05-22 5:21 am (UTC)

I see that mention of short file name issues has been removed from the article. I added it back as I found http://support.microsoft.com/kb/195144 which documents the issue.

The problem seems to be is that when Robocopy uses FindFirstFile and FindNextFile to scan the destination directory it's only looking at the cFileName field in the WIN32_FIND_DATA structure for matching long names. It's not looking at cAlternateFileName in the same structure which has the short names.

Here's a way to reproduce the issue. From a command prompt

echo test >TESTFI~1
echo test >"test file"
dir /x
01/09/2014  06:31 PM                 7 TESTFI~2     test file
01/09/2014  06:31 PM                 7              TESTFI~1

Now let's use robocopy twice in a row:

robocopy . test /njh /ndl /njs /np

            New File                   7        C:\tmp\test file
            New File                   7        C:\tmp\TESTFI~1

robocopy . test /njh /ndl /njs /np

            Newer                      7        C:\tmp\test file
            New File                   7        C:\tmp\TESTFI~1

dir /x test

01/09/2014  06:35 PM                 7 TESTFI~1     test file
               1 File(s)              7 bytes

It appears that TESTFI~1 was not copied. What happened is on the first robocopy it:

• Saw that "test\test file" did not exist in the destination and copied it as a new file.
• Saw that "test\TESTFI~1" did not exist in the destination as a long file name and copied it as a new file. Robocopy was unaware of that when it opened "test\TESTFI~1" that Windows matched that with the short name for "test\test file". Robocopy overwrote the contents of "test\test file" and updated its date/time stamp to match that of TESTFI~1.

When I did the second robocopy it:

• Saw that "test\test file" existed but that we had a newer copy. It updated "test\test file".
• Saw that "test\TESTFI~1" did not exist in the destination and copied it as a new file. As with the first time it copied robocopy was unaware that when it opened and copied the TESTFI~1 data into "test\TESTFI~1" that it was updating "test\test file".

The fix is not easy as you can't directly manipulate the short file names on remote volumes. If robocopy were to see that test\TESTFI~1 existed as a short file name then it would need to rename "test\test file" to change its short name, copy TESTFI~1 to "test\TESTFI~1" and then to rename the original file back to "test\test file" which will cause windows to generate a new short name that does not conflict with TESTFI~1. That's getting beyond the scope of Wikipedia. :-) --Marc Kupper|talk 03:27, 10 January 2014 (UTC)

Short Name vs Long Name Conflicts

In addition. Where a directory contains long file names that conflict with short file names then robocopy will report in the log that both files have been copied (100%) and that no files have been skipped, in the summary, but in actuality only one of the files will have been copied. This situation can occur when the originating directory is on a network file server and the destination is a Windows system. Many NAS servers and Linux servers allow this to occur because they do not respect short file names in the same manner as Windows!

This will also occur on a Windows system if robocopy is used to merge two different source directories into one single destination directory where a short name vs long name conflict occurs. Robocopy will not report any errors and will report the file has been copied. The order effects the outcome. Robocopy the short name file first and both robocopys' will succeed. Reverse the order and robocopy will fail.

Walter.Zambotti@police.wa.gov.au (Digital Forensic Investigator) 31/03/2017  — Preceding unsigned comment added by 203.59.131.86 (talk) 03:14, 31 March 2017 (UTC) 

GPT vs NTFS filesystem

Proposed Change Is there any limitation known for robocopy when used with a different filesystem than NTFS such as GPT? If GPT is a perfectly acceptable filesystem for it's use, then I the first line of the page should be changed where it mentions NTFS. It needs to include GPT or just generically mention the filesystem. eximo (talk) 16:38, 7 January 2010 (UTC)

GPT is not a file system, it is a format of a partition table, which is not part of the file system at all. It is the record on the drive that says where the file systems are located, and it is found outside - not inside - those file systems. When that is understood, the clarification isn't really needed, any more than it would be necessary to say that Robocopy works on both ATA and SCSI drives. The answer is of course, so long as Windows can see the filesystem. The same goes for anything that looks like a filesystem to Windows, including CD drives, network shares, FAT partitions, floppy disks, etc. Reswobslc (talk) 17:17, 17 April 2010 (UTC)

Command-line reference

There is no real need to include full list of option in the article. I've added an external link to a comprehensive description of Windows Vista/Server 2008 version of Robocopy in the TechNet Library, http://technet.microsoft.com/en-us/library/cc733145(WS.10).aspx --188.123.237.4 (talk) 15:50, 15 March 2010 (UTC)

No you did not add a link to a comprehensive description. The description of many of the options in the TechNet Library lacks a lot to be desired. Which is probably why better descriptions was made here by many good contributors. I have benefited a lot from those better descriptions. Now someone has deleted it and I can't find it anywhere else. To the person who deleted it: Please don't delete without first making sure that the info is somewhere else and there is a link to it. --AndersHM (talk) 07:21, 25 October 2011 (UTC)

TWO versions of Robocopy XP027!!!

From this page:

http://www.out-web.net/?p=663

There are few different versions of Robocopy though:

1.) XP010 – version from Resource Kit that is being used by most administrators

2.) XP026 – updated version, however it’s not easy to get it

3.) XP027 – new version built-into Windows Vista

4.) XP027 – new version built-into Windows 7

Even though version number is the same, Windows 7 version of Robocopy contains some improvements – /MT parameter. Default value is 8, maximum allowed is 128.

With /MT, you can specify how many threads will robocopy use to copy files. I was really curious about these results, so I decided to give it a try and test how different versions of Robocopy compares. For each test I decided to do combination of following variables: files count, files size and number of threads.

First, let’s compare versions 10, 26 and 27. On horizontal, you can see amount of files (100, 1000 and 3000). Lower number is better (amount of time needed to copy those files)................. —Preceding unsigned comment added by 71.252.64.50 (talk) 17:05, 15 March 2010 (UTC)

Here is one more addition. http://support.microsoft.com/kb/2646535/en-us --114.22.51.60 (talk) 02:24, 11 September 2012 (UTC)

Junction Points

A mention on Junction points and how they can cause un-intended recursion might be worth putting in the article somewhere. — Preceding unsigned comment added by 121.98.221.148 (talk) 08:18, 8 June 2011 (UTC)

Alternate definition

Should it be added that Robocopy could also be a word used to describe someone acting like Robocop? HotshotCleaner (talk) 07:26, 25 October 2011 (UTC)

Version number ?

Dear Sirs,

This is new for me but I have a question/remark for the author of this article.

You state that there is a product version 6.1 of Robocopy.exe in Windows 7. File Version is 6.1.7601. This I cannot verify.
I think that you mean that the Windows Version is 6.1.7601 of Windows 7. That is what I get when I give the command ver in a DOS box. I have Windows 7 Ultimate SP1.

When I check the file properties of Robocopy.exe I get the following information:

Fileversion: 5.1.10.1027

Productname: Microsoft Robocopy

Productversion: XP027

When I give the command robocopy /? I do get the options /DCOPY:T and /MT[:n]. Which gives me a clue what is stated in http://www.out-web.net/?p=663 is true ? I only used the option /DCOPY:T and this works !!

Again what I want to know is, if version 6.1 exist, how can I verify the existence of it and where can I find it ?

Thank you. — Preceding unsigned comment added by ComputerNerd75 (talk • contribs) 16:35, 3 May 2012 (UTC)

Here is robocopy version 6.1.7601 . However, it was not bundled. --114.22.51.60 (talk) 01:52, 12 September 2012 (UTC)

Incorrect feature description: date of incomplete files

The current version states (section "Features"): "incomplete files are marked with a date stamp of 1980-01-01".

This is neither exact nor really true:

(1) It would be helpful to also mention the file time, not only the date.

(2) It is not mentioned which of the three time stamps is set (creation, last modification, last access).

(3) As a test has revealed, January 1st is not generally true.

According to the mentioned test it looks as if the date was set to midnight of January 2, 1980, UTC. For all of you whose local time represents the western hemisphere (excl. GMT/UTC) this, indeed, appears as January 1st when displayed as local time, as e.g. in Windows Explorer. In my case (Central European time, +0100) a file time of Jan 2, 1980, 01:00 was displayed.

This file time was used only for the last modification date; creation date and last access date were set to the current time. (Please note that this refers to incompletely copied files; I haven't checked it for completely copied ones.)

So I guess that the topic should read something like: "incomplete files are marked with a last modification date of 1980-01-02 00:00:00 UTC".

Can anyone of you tell whether this assumption really holds?

94.216.168.121 (talk) 04:50, 20 April 2013 (UTC)

Spam

Can measures please be taken against the repeated advertising attacks? See e.g. (Undid revision 570716968 by 72.66.17.100) 84.24.61.65 (talk) 07:14, 30 August 2013 (UTC)

As it comes from different IPs we would be forced to protect the page against every IPs (including you) during a short period of time. JackPotte (talk) 21:25, 31 August 2013 (UTC)

Pun on RoboCop?

Is it a pun on RoboCop (the film franchise), or does robo- just suggest automation of a task (robotics)? 86.136.110.44 (talk) 00:13, 24 July 2014 (UTC)

I can't find any interviews or other sources from the original time period discussing this, but I'd be surprised if it wasn't a wink in that direction, anyway. The official line is that it stands for "Robust Copy", but they didn't call it "Robucopy". Ironphoenix (talk) 19:14, 3 January 2023 (UTC)

When using /J, read only volume cannot be made a source

This bug fixed in Windows 10.--211.127.228.179 (talk) 17:12, 7 July 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Robocopy. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20100317020028/http://www.zdnet.com.au:80/blogs/snorage/soa/Microsoft-s-Robocopy-compromise/0,2000064373,339291041,00.htm to http://www.zdnet.com.au/blogs/snorage/soa/Microsoft-s-Robocopy-compromise/0,2000064373,339291041,00.htm

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 10:18, 19 February 2016 (UTC)

Robocopy seems to be able to copy open files contrary to what the "No open files" section says

I've found that as the "No open files" section states that with and without the /B switch robocopy cannot copy open files. But with the /ZB switch it seems to be able to copy open files just fine (haven't tested only the /Z switch). This was tested on Windows 10 running Robocopy as admin. Am i misunderstanding this or is this a hidden bonus? 84.105.57.204 (talk) 00:49, 14 May 2016 (UTC)