This is the
talk page for discussing improvements to the
Robocopy article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
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)
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)
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)
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)
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)~
"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)
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)
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)
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)
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)
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)
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)
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)
The example is fubar. Iowaseven ( talk) 00:38, 15 February 2009 (UTC)
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
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:
When I did the second robocopy it:
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)
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)
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)
From this page:
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)
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)
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)
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)
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)
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)
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)
This bug fixed in Windows 10.-- 211.127.228.179 ( talk) 17:12, 7 July 2015 (UTC)
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:
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: 5 June 2024).
Cheers.— cyberbot II Talk to my owner:Online 10:18, 19 February 2016 (UTC)
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)
Is robocopy bundled in Windows 11? If not, how can it be downloaded? — GhostInTheMachine talk to me 13:05, 13 July 2024 (UTC)
This is the
talk page for discussing improvements to the
Robocopy article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
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)
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)
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)
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)
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)~
"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)
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)
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)
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)
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)
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)
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)
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)
The example is fubar. Iowaseven ( talk) 00:38, 15 February 2009 (UTC)
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
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:
When I did the second robocopy it:
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)
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)
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)
From this page:
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)
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)
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)
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)
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)
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)
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)
This bug fixed in Windows 10.-- 211.127.228.179 ( talk) 17:12, 7 July 2015 (UTC)
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:
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: 5 June 2024).
Cheers.— cyberbot II Talk to my owner:Online 10:18, 19 February 2016 (UTC)
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)
Is robocopy bundled in Windows 11? If not, how can it be downloaded? — GhostInTheMachine talk to me 13:05, 13 July 2024 (UTC)