Comment by UnoriginalGuy | Hacker News Reader

Comment by UnoriginalGuy | Hacker News Reader

Parent Full thread

Inaccurate title.

Windows currently doesn't have a 260 character path length limit. However some legacy Win32 APIs only support up to 260 characters for backwards compatibility and old file system reasons.

If you use UNC paths you can have a path with 32,767 characters in it, 255 characters per element (e.g. a single folder/file name of 255 characters).

To quote MSDN:

> The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

All this GPO policy does it change existing non-unicode Win32 APIs to support paths beyond the 260 character limit. However this likely won't work on pre-Windows 10 versions of Windows, non-NTFS filesystems, and just having long file/folder names may within itself break older software.

> However some legacy Win32 APIs only support up to 260 characters for backwards compatibility and old file system reasons.

Legacy or not, this affects all .NET applications and also to some extent NodeJS (with its crazy node_moules mess) and you have to apply all kinds of crazy workarounds for this not to come back and bite you.

The amount of builds I've seen broken over stuff like this is ridiculous.

If they can get this fixed proper, I'd love to offer the MS engineer who made this happen a beer or twelve.

speaking of this, how do you do delete those crazy node_modules in Win10 from the command line? Powershell or CMD

Lots of options here: http://superuser.com/questions/256105/how-do-i-delete-a-fold...

If you have 7-zip installed, you can open the parent directory in 7-zip file manager and delete it from there.

https://www.npmjs.com/package/rimraf

One approach (which I've used in our build definition where we ensure we have a clean workspace) is to rename all folders to "a" and recursively dig into them before deleting.

So \a_quite\long\path\with_files\module.js becomes \a\a\a\a\module.js

And you can usually delete that quite fine.

It's terrible. It's ugly. But it works.

rmdir should do the trick:

https://www.microsoft.com/resources/documentation/windows/xp...

Although installing MSYS2 http://msys2.github.io/ provides a far superior command line environment IMO and then you can just use rm.

Indeed it does. You could talk about Windows the entire operating system, or you could talk about Windows as Win32, but either way - yes - they both have 260 character path length limits _by default_.

I realize that you're saying that Win32 doesn't have a hard limit of MAX_PATH since you can use Win32 file namespace paths (the `\\?\` prefix) to specify long paths. And yes, that's technically correct, you can. But realistically, unless you carefully control the paths that you're writing and no other program is using them, you're pretty much shooting yourself in the foot by trying to do that.

This is because most apps simply use the Win32 APIs with normal paths and not Win32 file namespace paths. So sure - you can write a file that has a name that's 1024 characters, or a file named `CON`, or a file named `hello?`, but only other programs that wisely use `\\?\` paths can do anything with that. Which is basically nothing except the program you just wrote.

It certainly doesn't include almost anything that Windows itself put down during installation. `cmd`, the Windows Shell, the whole of the CLR? None of these can read the file you just wrote.

So the title seems quite accurate to me.

This is second hand information; but a developer at my place of employment tried to get around path limitations by applying UNC paths and was met with many, many barriers where windows internals themselves only understood the legacy version of paths and the UNC "limitless" approach didn't actually work.

this was on windows 7 though and relatively recently, perhaps it's better in 8 and 10.

If I recall correctly this change didn't just need a GPO setting, but also a .manifest file for the executable (often embedded)? In order to tell the OS that "Yes I am now a Windows 10 long path aware application; bring it on." Otherwise yeah, it would wreak havoc on apps using buffers with MAX_PATH size.

I have hit this limit when trying to make backups with rdiff-backup (written in Python) on relatives' computers. I found out about UNC paths that way, haven't managed to get rdiff-backup to accept them. Does anyone know how to do that?

> rdiff-backup (written in Python)

"If you have ever needed to work with UNC paths in a Python script for Windows, you might have experienced the same dilemma that we did. What’s the problem? Python has virtually no support for UNC."

http://developer.covenanteyes.com/unc-paths-with-python/

"As tiny as our minority might be, we wanted to deal with these difficulties once and for all. I introduce to you the win_unc library."

Hmm. This looks like it deals with UNC paths. I think the parent is asking about what are sometimes called "Win32 file namespace paths" - or at least defined as such by the MSDN article that is canonical https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

These are sometimes erroneously called UNC paths because, well, they _look_ like UNC paths. But UNC paths are used to refer to a path on another host. (In fact, you can specify UNC paths using the Win32 file namespace using the `\\?\UNC\server\resource` mechanism.)

It looks like win_unc will help with UNC, but it looks from a quick glance that it will not help with `\\?\` paths.

I've never used it. If it doesn't work and somebody really needs to have "\\?" in Python and doesn't want to develop the Python extension in C himself, I'd be willing to develop it, but for money, serious consulting rates.

Reply on news.ycombinator.com