Wednesday, December 17, 2014

Regarding the Long Path

I shared my post regarding the Windows long path dilema on the /r/sysadmin subreddit and on G and quite honestly there was quite a reaction. Thank you everyone who took the time to read my article, and I wanted to share something that /u/elkBBQ shared


I had a good chuckle, but on a more serious note. I learned quite a few things from the /r/sysadmin community but I did want to clarify for those who still believe that this is a limitation in the file system (NTFS), but let me tell you it is not. NTFS actually handles up to 32k characters on paths; however, Windows is not able to use it because of a limitation in its API, and while there is some ways to force it like using Unicode and other ways to get around the issue (see link below) there is no office or really a 'good' solution.

I wanted to share the following Article that explains a lot on this issue. The article is written by Kim Hamilton of the BCL Team and as (s)he explains in an answer to a comment:

We do need a solution in the underlying windows API, but this would most likely emerge as new APIs rather than changing the existing ones. We've discussed this at length on the longpath alias at Microsoft (yes, we have a whole alias devoted to the issue!) and there are no plans to change the existing ones, since it would break third party code that depend on MAX_PATH buffers on the stack.
We've discussed migration plans to enable those existing Win32 APIs not to enforce MAX_PATH but there are no clear solutions; this would need to be done very carefully to avoid breaking existing Windows-based apps.
The main reason I think we need new Win32 APIs is that \\?\ lumps together long paths and non-canonical paths, so you have to do tricks to get canonicalization on \\?\ paths. That sort of work shouldn't be pushed onto the callers just to achieve long paths.

Date: 13 Feb 2007 7:08 PM

Sadly in 2007 Microsoft believed this was an issue, and their team were working on a solution. It has been 7 years  and the issue still persists, and from what we know off there is no soon to come fix.

Kind regards to everyone,

PS. Below I'll post some of the most common work arounds for this issue:

Force Unicode: \\?\PATHHERE (please see the link above for details on how to use this method)
Con: Not widely supported

Map a drive or use subst to map a drive.
Con: Unfortunately the only way to get this to work would be to know the exact path. You'll have to map the drive to a subfolder that is close to the one that breaks the limit. Also doesn't play very well with scripting.

Someone (and I apologize I cannot find the user who posted this on the reddit post)  recommended to use VBScript; however, I do not posses this skill, so if someone could show us a way for this that'd be awesome!

Peter Kriegel pointed me to a PowerShell Module called  File System Security PowerShell Module 3.2.2 but I'm not familiar with it and haven't had a chance to look deep into it as to try to find out who they manage to make it work. Again if someone has some information that they can provide regarding the inner workings, or if indeed truly works I'd appreciate the information.