The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Write a design guide, put a "printed" date on each page of [x] years before the new BA started, give it to the dog to sleep on for a few nights, then refer to it whenever he gives you work. Just point out it's non-conformant. When he asks why no-one's produced it before, just say it's so internalised that it's second nature to everyone. But must be adhered to.
If you remove all the folders on the source it'll not only work, but be much faster too.
better yet, try FORMAT - can't think of it right now but there's a switch that'll make it work.
after many otherwise intelligent sounding suggestions that achieved nothing the nice folks at Technet said the only solution was to low level format my hard disk then reinstall my signature. Sadly, this still didn't fix the issue!
I have always used xcopy with the /d for anything with a newer date than the target.
If that's the goal, then this is how I've always used robocopy:
robocopy source target /MIR /R:0
Even though my backup set is measured in terabytes, the above only copies what's actually changed at the source (and deletes what's been removed), and only takes a few minutes. That's been reliable for me and that's what I've been using for nearly a decade.
Long path names are either handled correctly already by robocopy, or I've just been very lucky and have never encountered them. Must be the first one, because when it comes to this sort of thing, luck is rarely on my side.
I saw this link before posting and it didn't help me with a long path over 300 C, so I am posting here
..the program that I mentioned before solved the problem, but can you apply the solution in the link you shared? maybe I have a technical problem which prevents me from applying it !!
can you apply the solution in the link you shared?
I'm not sure I understand. The only link I provided was to a StackExchange discussion that mentions robocopy should support long paths out of the box, and before that, a sample of how I use the command myself.
This article shows various ways to enable NTFS long paths in Windows 10, but looking at the registry on two of my systems (one of which is my NAS, which is what I use robocopy against), it looks like I don't have it explicitly enabled...so I'm not sure if it's necessary. OTOH, my "NAS" is running Windows 7, so it can't be a "recent version of Windows 10"-only feature.
I realize this will come across as a lame suggestion, but is there any chance you can organize your folder structure so it doesn't run so deep? My NAS is essentially my archive of all my documents, music, source code, CD/DVD ISOs, installers, etc...and--unless robocopy is failing silently--I've somehow managed to avoid running into the path limit, and this is the "live archive" I've been using for 10+ years. In fact it's unlikely to be the case, because now that I think of it, even the last time I moved my entire set of files from an 8TB drive to a 10TB drive, I compared the total amount of data on the original disk with the target, and I got a match (down to the byte), so I know nothing got left behind because the path was too long.
Another thought (again, rather lame): Is your drive formatted as NTFS?
I see in another response in this thread that you've found a solution using another tool - good to know. I honestly don't know at this point what to suggest might be wrong with robocopy.
, but what does this comment mean "what to suggest might be wrong with robocopy." ?
I simply meant to say I don't know why robocopy isn't working in the expected way in your case. Because if the discussion at the link I had provided is accurate, then robocopy should already support long paths and it should "just work". But clearly it doesn't, at least in your particular situation.