Implement native robocopy cmdlet
Votes from Connect: 72
Original Date Submitted: 2/23/2011 3:47:03 AM
Description:
********Contact Information********
Handle: Joel Reinford
Site Name: PowerShell
Feedback ID: 646172
***************************************
Frequency: Always Happens
Regression: Yes, this happens in all previous versions
Problem Description:
Powershell needs the full functionality of Robocopy as a cmdlet. Copy-Item has too many limitations and invoking robocopy from Powershell is not an elegant solution.
Product Studio item created by Connect Synchronizer due to creation of feedback ID 646172 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=646172).
Repro Steps:
Expected Results:
Internal BugId: 2822
AdminJoey Aiello [MSFT]
(Program Manager, Windows Server)
shared this idea
Tracking a list of missing robocopy-like functionality in this GitHub Issue: https://github.com/PowerShell/PowerShell/issues/2581
Feel free to continue to vote here, but you’re also welcome to add comments there or even contribute some of the missing functionality!
15 comments
-
LUVoice
commented
I think it should be a separate function, not just Copy-Item. Perhaps Invoke-NtfsSync? Might be useful, though, to also supplement Copy-Item with some Robocopy smarts when copying NTFS to NTFS. Stepping back ... a new more robust filesystem for Windows may be just around the corner ... May need to consider uniting BITS and Robocopy functionality in new command(s). Just some thoughts.
-
LUVoice
commented
Please can a 'validate' function be included? It might be prioritized after the like-for-like functionality, but I'm sure an optional parameter to 'validate' transferred data would be valuable.
-
Ross
commented
/COPY:DAT is a common use for me
-
Josh Castillo
commented
Robocopy is the closest thing to RSYNC for Linux that windows has. It really should check file hash, check attributes and be able to mirror in general. Also, the being able to boost thread to increase performance would be important.
-
Patrick.Franchise
commented
The Robocopy features that I use the most:
/COPYALL
Only newer, changed, or new files
Only files of X size or Y age
/z Restartable mode
/B backup mode
Automatic retries and waits
Long Path support
/IPG:n to run the copy slowly, for all sorts of reasons
/J Unbuffered I/O
The progress / no progress is really great too
/Create for the directory tree and zero-length files.Really I want and have used everything.
I think there should be a separate cmdlet to implement all of robocopy's features. Copy-Item could implement the /COPYALL, copy only new/changed, and /MIR. An automatic hookup to Write-Progress would be great. But Robocopy does so much, and has so many features that it would be a mistake to re-implement them all in Copy-Item. It would throw too many options at people who just wanted to copy a file from A to B, especially when first learning PowerShell. Write a Copy-ItemRobustly cmdlet. -
jnky
commented
The most important robocopy features to me are:
* /mir et al, so as to copy an entire tree to a destination, purging the extraneous files/folders
* /b to copy files/folders as an admin (backup operator) without having explicit rights to the files/folders
* /copyall etc. to copy permissions and flags along with the data itself.The features above are invaluable when copying user profile folders or the folder redirection destinations for a bunch of users, which is something that an administrator may want to do occasionally as part of his duties.
-
Toby Patton commented
Personally I would like to see ALL the features of robocopy.
If you could make it a parameter for example Copy-Item -Robocopy -OtherDetails/SwitchesHere
That would be great!
-
Craig Woodford
commented
I'd also add that the /MT switch in Robocopy is very valuable. Being able to multithread large file copies is also vital.
One of the reasons I would love robocopy functionality in a powershell cmdlet is pipelining. I'd love to pipe the output directing into some parsing code so I can grab only what I need from it.
-
Willsatroyd
commented
Sync with mirror option are the most important.
-
Louis Kiphen
commented
1) Sync destination to source (only copy over new/different files, optionally delete orphan/extra files from destination)
2) Retry 'X' times with timeout of 'n' seconds (user-specified)
3) Error action: continue copying on error and give error at end of action (Each 'try' in a retry would attempt to copy each uncopied file once)
-
Mark Fowler
commented
The most important enhancement is the synchronisation aspect - only copy the files that differ from source to dest, optionally deleting extras (as per /MIR).
But just how comprehensively do you replicate Robocopy's functionality?There's the mode that it runs in - restartable, backup, EFS Raw, move files, create empty files, list the differences, monitor source, etc
Monitor source and rerun are probably more appropriate for a separate set of commands - similar to the Windows Server Backup Cmdlets - a suite of cmdlets that set up the job and run it, vs the WBAdmin.exe commandThere's what gets copied - data, attributes, timestamps, security, owner, auditing, etc
(Here's a copy for you to use vs This is a backup that is an exact duplicate of all characteristics of the files)The filtering options - include or exclude based on timestamp, size, attributes, etc
The retry options - number of retries and wait time
The logging options - probably not so relevant to a cmdlet - output full status objects per file and use powershell Select-Object and Format-Table/List/Whatever to format
In summary - the ability to do a sync is really important (to me). The ability to do all the other stuff (mode/filter/etc) will make it easier to replace robocopy with native Powershell.
-
Rob Cannon
commented
The three core features of RoboCopy that we use are:
1) Copies will not overwrite files from the source that are already in the target (based on last write date). This greatly speeds up some operations.
2) The /MIR switch to mirror a source directory to a target directory (removing any files in the target that are not in the source.
3) Automatic retries to keep retrying when a file is locked or the destination is unavailable for some reason
-
Jason Fossen
commented
>>>what does Copy-Item need to get parity with robocopy?
Long path support by default (both NTFS and ReFS).
/R and /W automatic retry and gracefully moving on when files can't be copied (no terminate on first failure).
/MIR option to sync a source and target directory tree (DSC needs this).
/XF and /XD options to exclude certain files and directories.
/EFSRAW to copy encrypted files (Win10 Enterprise Data Protection might need this too).
/LOG+ to a CSV log file for PoSh-parsing, especially the copy failures, with error code explaining the copy failure.
(More Robocopy switches would be nice, of course, but the above would be my short list of must-haves before considering stop using Robocopy. Thanks for taking the survey!)
-
Tim Curwick
commented
Compare-Object ( robocopy /? ) ( Get-Help Copy-Item -Parameter * )
Until Copy-Item can do everything robocopy can do, and can do it just as quickly and reliably, we are going to be forced to continue using robocopy.
-
Jason Fossen
commented
Enhance the existing Copy-Item to be more like Robocopy, not create a new cmdlet with a different name (I think this is what Joel meant in the original post). Most importantly, Copy-Item must be able to deal with long paths (this kind of MAX_PATH limitation is embarrassing and drives Unix people crazy...and away from PowerShell). This should have been fixed *years* ago. And we need this same kind of Robocopy reliability for DSC too.