Grrr! I really hate Windows sometimes.
I need to move a user’s home drive from one partition to another, only I can’t because the paths and filenames are too long to read!
If the paths and filenames are too long to be read, why the heck did Windows Server allow the files to be written to disk in the first place!?!?
Now having to go through the 1,609 folders and 10,066 files to find the 220 it couldn’t copy, rename them to something shorter and manually copy them over…
Yes, Windows sucks sometimes…
Microsoft is so bad that way. I don’t use windows, but I use OneDrive. I had to rename so many files when I uploaded them. Lucky on mac I was able to do it in batches since it wasn’t a length issue, but that I had used symbols MS didn’t like.
Abso-fragging-lutely, as Captain Sheridan would say.
That is slightly different, it stopped you from uploading them, because they were too long/had illegal characters. That I can accept. Here, Windows actually wrote the files to disk, then complains that the filenames are too long when you try and read them!
Oh, wow, that it really bad. I am even more glad that I good hooked on the apple 10 years ago. Not that it is perfect, but I don’t find myself ripping my hair out as often.
This is a limitation some win32 API calls (but not all of them) not the NTFS filesystem. This is why you can have files that have paths that are too long. It is a massive PITA.
Use robocopy and UNC paths when you run into this. It doesn’t have the same limitation and is usually faster.
I usually use robocopy "\\SOURCE\UNC" "\\DESTINATION\UNC" /s /zb /secfix /copyall /mir /r:3 /w:3 /MT:64 /v /log:C:\loglocation1
Add /sl to prevent robocopy from follwing symlinks
Make sure to read the docs before using it:
Yes, it comes from mapped drives.
But the point is, this has been a big in windows for more than 20 years. Why haven’t they sorted it out by now? It is hardly rocket science.
The short answer is they can’t fix the API without breaking legacy software.
I remember using an old third party utility called YCOPY in the days of Windows XP that was sensible enough to write a log entry for any file it couldn’t copy then move on to the next. Saved me lots of time with disk to disk copies, especially with your issue.
@big_D, this was in reply to your post but it seems to have lost the connection when I posted it.
There is a registry entry you can change in Windows to make it deal with long files and paths in a more friendly way, but it is not set by default because it could potentially break software. Apps that know what they’re doing can also use a magical incantation to inform windows they support long filenames and paths… it is \\?\ prefixed to the filename, and then the rest of the filename is in Unicode.
https://www.itprotoday.com/windows-10/enable-long-file-name-support-windows-10
EDIT: apparently backslashes are special in the BBcode for Discourse and you need to double up to get one, so I edited the path to have have four backslashes in the BBcode so I could get two of them to show together.
As for how you can build a path you can’t read later, remember that not all paths are absolute paths. If I create /a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/q/r/s/t/u/v/w/x/y/z and then go into the z directory and make the same path without the leading slash, known as a relative path (in front of the a) now I have a path that is 52 levels deep… repeat as necessary.
Now ideally the OS would translate ANY relative path into an absolute one to make sure it can be resolved, this would probably significantly slow down file access by causing the OS to seek all over the disk to resolve and verify file paths before opening them.
There’s the subst command that can take a UNC path already mapped from (net use) and make it more relative and there is a program that can make text files of long paths and file names and also copy or delete them Long Path Tool - so maybe give that a try.
Maybe try booting into a live distro of Linux to “copy” not move
On a live production server? No, I really like my job, thanks anyway. 
You could and should script the operation of finding the files with the long names.
It will probably be faster and you will have a tool that you can reuse in the future.
Will probably be a limitation in Windows for a long time. We do big data migrations as well, robocopy is the key in this scenario. Bypasses this length limitation and if you use the right switches you can get a nice log file of all its actions.
Yes, but VSS and the backup software don’t always. That leaves the files unrecoverable, if they get corrupted / deleted.
Correct. That is one reason in our environment where I work (granted, we handle about 2.5PB of data) we use storage systems that are BSD Unix based.
My bad , I missed the “live server part”