Robocopy too long path & NTFS Permissions

AveryLiam

New Member
Reaction score
0
Location
US
I am using Robocopy to copy our files from windows server 2012 R2 to windows server 2019 ,I have 2 issues :
-After copying 10 G , the destination data checked and we found that some permissions not copied or applied there (NTFS permissions )
-We have errors informed us that some files pathname are too long (over 200 paths)
- Is there a way to copy the changes only that occurs on the source to server 2019 automatically using Robocopy ?
I had the chance to try some solutions but the problem still exists

Any assistance would be appreciated
 
And consider, strongly consider, reworking the folder architecture so that this issue does not recur.

There has been a ton of recent discussion here about the 256 character maximum fully qualified file name length under NTFS. That limit should always be honored so that this sort of issue does not recur.

What's maddening to me is not the name length issue, but that it is possible to get around it and have things work in specific contexts, but if you need to do a mass migration you're screwed. This limit should be enforced without exception by the OS itself, but it isn't.
 
Robocopy by default copies only changes from source to destination.

/mir and /e are the switches to look at. These switches however are all about what gets copied, not how. The how is always a directional sync.
 
Robocopy /MIR
Robocopy by default copies only changes from source to destination.

/mir and /e are the switches to look at. These switches however are all about what gets copied, not how. The how is always a directional sync.
@Philippe @Sky-Knight
these switches already been tried , it copies the whole source folder again not the updates and not all the permissions copied
 
And consider, strongly consider, reworking the folder architecture so that this issue does not recur.

There has been a ton of recent discussion here about the 256 character maximum fully qualified file name length under NTFS. That limit should always be honored so that this sort of issue does not recur.

What's maddening to me is not the name length issue, but that it is possible to get around it and have things work in specific contexts, but if you need to do a mass migration you're screwed. This limit should be enforced without exception by the OS itself, but it isn't.
@britechguy
thanks for the advice but shorten the paths unfortunately is not an option because our works needs the paths to be copied as it with its structure ,and 200 paths or more are not something easy work on :)
 
Teracopy. Or try Rich Copy. Sounds a bit like an EU question...
I always found that unstoppable copy handled long names good, I know it's older but it has a tonne of options.
@Mick @NviGate Systems
LOL .. I heard about such tools and other similar tools, I didn't use tools like that before .. the main purpose for me was to perform these tasks using the Robocopy but I think Robocopy is missing a few things, I think finally I'll give a look to these tools .
many thanks
 
Robocopy /mir /sec as has been said will mirror from source to destination with security.

Notes that your machines must be on the same domain to maintain the security.

Be careful with the Mir parameter though because if you get the Paths the wrong way round then you can wipe the source folder.

If a lot of the characters in the path are eaten up by folders then you can temporarily share one of the the deeper folders in the path and robocopy using that instead. Obviously update the destination folder at the same time.

Or use a more user-friendly method as recommended above
 
Many years ago, I learned of this tool from a Microsoft server support guy while working with him on some issue that I can't remember.

Great tool rich in features...have used it ever since when doing server migrations. Have used/tried many others..and always find this the best.
 
the advice but shorten the paths unfortunately is not an option

While it certainly may not be an option in the short term, it's essential over the long term if you wish to have this episode, or another quite like it, prevented from occurring again. That's really my central point. Someone needs to be doing some clean-up work to prevent this kind of mess from occurring in the first place as time and resources permit.
 
While it certainly may not be an option in the short term, it's essential over the long term if you wish to have this episode, or another quite like it, prevented from occurring again. That's really my central point. Someone needs to be doing some clean-up work to prevent this kind of mess from occurring in the first place as time and resources permit.

I'll repeat this also.
If you try to ignore it, and get around it, it'll just surface its ugly head again down the road. Could be sooner, could be later. At some point in time, File Explorer will be used to move/copy a bucket of stuff...and...BOOM...here we go!
Might happen to the end user...probably not, because they often don't copy whole folders...but it might.

Will likely happen when you go migrate their server to a new server. This is often how this problem begins. Let's face it, since the days of Novell servers or DOS/NT 3 servers ...office networks have had a big "shared" drive. Typically the IT guy to migrate them to a new server every 7 or so years....just got lazy and copied that whole bucket to a new server. 5 or 8 years later....same thing again! And again...and again. Rarely was the opportunity taken to re-organize, neaten things up.

Where it may also happen to you is...during a big data restore...something happened to the server to make you reach for a backup...so you can copy things back, and depending on that type of backup...with most newer backup software ..file explorer can be involved. BOOM...here we are with this issue again! But this time you're under stress!

Should look at this as an opportunity to work with the client and re-do things from the ground up. Yup..takes time...but roll this into the project.
 
Should look at this as an opportunity to work with the client and re-do things from the ground up. Yup..takes time...but roll this into the project.

Not to mention to educate the client about why this should never, ever be done again unless some change to NTFS that allowed longer paths were to be introduced. I doubt that will ever happen.

Work within known constraints. It saves a s*itload of heartache!
 
Many years ago, I learned of this tool from a Microsoft server support guy while working with him on some issue that I can't remember.

Great tool rich in features...have used it ever since when doing server migrations. Have used/tried many others..and always find this the best.
+1 for Free File Sync. Very robust. I set one instance up for a client over five years ago and it hasn't missed a beat since. And, you can set it to wait for an external device (network device, USB stick, whatever...) to appear, then automatically start its routines. So, all lazy folks need to do is just plug something in or switch it on and then just walk away.
 
Back
Top