Just mentioning a trick I do not see mentioned here yet.
Take this file for example:
C:\Folder1\Really Long Path\Such Recursion\So Deep\Wow\Still Going\I will run out of ideas soon\I have organizational problems\Obsessive compulsive subdirectory disorder\Here is a guid for no good reason\936DA01F-9ABD-4d9d-80C7-02AF85C822A8\Almost there\Tax Returns\2013\2013_tax_return.pdf
This full file path is 290 characters long. The shell (Windows Explorer) and most command line utilities probably won't let you touch it.
Use the subst
command like so:
subst X: "C:\Folder1\Really Long Path\Such Recursion\So Deep\Wow"
Now you can access (and delete, move, etc.) the file thusly:
X:\Still Going\I will run out of ideas soon\I have organizational problems\Obsessive compulsive subdirectory disorder\Here is a guid for no good reason\936DA01F-9ABD-4d9d-80C7-02AF85C822A8\Almost there\Tax Returns\2013\2013_tax_return.pdf
And now that file name is only ~235 characters or so, so you will not encounter the "Filename is too long" problems any more.
In the Windows API, there is an infamous constant known as MAX_PATH
. MAX_PATH is 260 characters. The NTFS file system actually supports file paths of up to 32,767 characters. And you can still use 32,767 character long path names by accessing the Unicode (or "wide") versions of the Windows API functions, and also by prefixing the path with \\?\
.
MAX_PATH
was set in stone a very long time ago in the Windows world. I think it has something to do with ANSI standards at the time... but it's one of those things that's very difficult for Microsoft to change now, as now we have thousands of programs and applications, including some written by Microsoft themselves, that use MAX_PATH
and would fail in strange new ways if the constant were suddenly changed. (Buffer overflows, heap corruption, etc.)