Powershell: Improve Copy-Item to provide parity with Robocopy

Created on 1 Nov 2016  路  8Comments  路  Source: PowerShell/PowerShell

Copied from one of the top suggestions on UserVoice: https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/11087646-implement-native-robocopy-cmdlet

This is a collection of suggestions derived from UserVoice to improve Copy-Item so that it's as robust and feature-laden as Robocopy. (Special thanks to everyone in the UserVoice thread. I'm going to try and summarize all your requests as succinctly as possible here.) The bolded items were particularly popular in the UserVoice thread (and I sorted roughly from most to least popular).

Note that there was also some discussion about adding this functionality to a separate cmdlet so as to avoid complicating Copy-Item too much. I think there's probably a reasonable balance we can strike here.

  • [x] Deal w/ long paths (this works now!)
  • [ ] Support "retries on failed copies" (robocopy /R:n /W:n)
  • [ ] Support mirroring of a directory tree (robocopy /MIR)
  • [ ] Ability to copy "all file info" (robocopy /COPYALL)
  • [ ] Support excluding certain files and directories (robocopy /XF foo /XD bar). (Question: what is needed here that isn't fulfilled by Copy-Item -Exclude?)
  • [ ] Support "backup mode" where any admin can copy items without explicit rights (robocopy /B)
  • [ ] Support "restartable mode"/ability to resume file transfers (robocopy /R)
  • [ ] Support EFS RAW mode to copy encrypted files (robocopy /EFSRAW)
  • [ ] Support logging to a CSV file (robocopy /LOG). (Question: what is not already fulfilled by ConvertTo-Csv?)
  • [ ] Ability to not overwrite target files that match the source's last write date
  • [ ] Support multithreading (robocopy /MT[:n])
  • [ ] Support throttling of file transfers for low-bandwidth connections (robocopy /IPG:n for "inter-packet gap)
  • [ ] Support "copy using unbuffered I/O" (robocopy /J)
  • [ ] Support arbitrary Robocopy usage (Copy-Item -Robocopy -RobocopySwitches) (in my opinion, this isn't a great idea, especially given cross-plat)
Area-Cmdlets Issue-Enhancement Issue-Meta Up-for-Grabs

Most helpful comment

I think -NoClobber would be more idiomatic.

All 8 comments

Does long paths work with the shipping version of PowerShell?

@RobCannon Windows PowerShell in the Win10 Anniversary Update supports long paths, but you need to enable it for the OS (http://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters), PowerShell Core supports it by default

The first question is whether the functionality in core?

It consists of two parts:

  1. Interest of the community, I believe that here the answer is Yes.
  2. The ability to implement functionality in volume, which will retain the interest of the community.
    To answer the second part we need to do an analysis of what robocopy keys we can effectively implement (considering porting). If the resulting list will be good for the community, then we can go further.

How about just a -NoOverwrite to not overwrite target files, period ... (robocopy /XC /XN /XO??)

I think -NoClobber would be more idiomatic.

we need the options like "-ACL permissionsOnly" & "-NoACL" & "-ProgressBar $true" and
/mir -MirrorSource

I know many, many admins using Robocopy to do backups.

I allways say: if you do not check the integrity of your source <-> destination it is a copy not a backup!

So a verify mechanismm must / should be in the Process. This can be done by a separate cmdlet like Get-FileHash. But this should do it VERY fast and multithreded and IO / Network recource respectful.

So the needs to verify are very similar to Robocopy and they should work together.
So I think it also should be in the Robocopy box.

The Runtime Team is discussing a File.CopyAsync method here
https://github.com/dotnet/runtime/issues/20697
I think @JeremyKuhne is the right guy to ask.

Was this page helpful?
0 / 5 - 0 ratings