**Mise à jour :**
-
J'ai découvert que not only Explorateur Windows but also other software
suffers from too long path names. Par exemple, in Firefox, when I
save a webpage into a directory, I still cannot do it if its name or
path name is too long. Does Firefox also rely on Explorateur Windows?
Comment puis-je solve that problem too?
-
J'ai tried the software recommended in the two replies. None of
them can access a long path. Is the Long path problem inherent to
Windows OS, regardless of which program to browse directories? If
yes, does it mean there is no way to get around it?
**Original:** J'ai two OSes installed on my laptop: Windows 7 and Ubuntu 10.10. They share a partition.
In Ubuntu, by using Nautilus, I can create directories that are located very deep in the path hierarchy on the shared partition. But when switching to Windows, Explorateur Windows does not allow accessing directories that are located too deep, i.e. having too long path name.
Also Explorateur Windows seems not able to access files and directorates created under Ubuntu with special characters in directory and nom de fichiers.
I was wondering what can solve the problem in Windows? Par exemple, are there other alternative software to replace Explorateur Windows?
Alternative to Explorateur Windows for long path names
Re: Alternative to Explorateur Windows for long path names
While NTFS allows paths some 32,000 characters long, you've found the [259-character path length limitation of the Win32 API](http://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath).
>
In the Windows API (with some exceptions discussed in the [linked document]), the maximum length for a path is `MAX_PATH`, which is defined as 260 characters.
(There is additionally a `NULL` termination character appended to the path, giving us 259 usable characters.)
Because Explorer (and almost all other Windows apps) rely on the Win32 API for filesystem access, it's not *practical* to get around this limitation even though it is *possible*:
>
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. Par exemple, "\\?\D:\very long path".
Malheureusement, you can't just type `\\?\D:\very long path` in to an Explorer window. The application must be designed to take advantage of these APIs and handle very long path names.
One way to access extended-length paths under Windows is to install [Cygwin](http://www.cygwin.com), a *nix emulation layer for Windows. In my testing, Cygwin does not appear to be limited by `MAX_PATH`; bash and vi had no problems with paths 2,000 characters long.
Gardez à l'esprit that even though vous pouvez utiliser bash to browse extended-length paths, you probably won't be able to open files in those paths in regular Windows applications. Par exemple, typing `notepad` while the working directory is an extended-length path gets you
>
Error: Current working directory has a path longer than allowed for a Win32 working directory. Can't start native Windows application à partir de là.
And trying `notepad "\\?\D:\very long path\file.txt"` doesn't work either; it launches, but just says
"Can't find file ..." Trying the same with [Notepad++](http://notepad-plus-plus.org/) crashes it. (Probably a buffer overflow.)
Your other option to access specific files buried deep within an extended-length path is to *shorten the path itself* by creating a NTFS [junction point](http://en.wikipedia.org/wiki/NTFS_junction_point). From an elevated invite de commandes:
```
D:\> mklink /J jct "\\?\D:\very\long\path"
```
Vous pouvez now access the contents of `D:\very\long\path\` from `D:\jct\`. You won't hit any path length problems because as far as Explorer and other apps are concerned, the path is just `D:\jct\` (or whatever). The NTFS driver handles redirecting the path (the "reparse point") transparently.
The downside to this approach is obviously that vous devez create a junction near the file you want to access; you still can't simply browse the entire directory structure.
Regarding special characters (`" * : < > ? \ |`), that's simply a no-go. Those characters have special meanings within Windows, so it's not possible to use them within paths. (Cygwin allows you to create files with special characters, but it does so by [substituting the characters](http://www.cygwin.com/cygwin-ug-net/using-specialnames.html) with special Unicode characters, which it then substitutes back when reading. Viewing these Cygwin-created files under Linux or in Explorer wouldn't look right, since the Unicode characters wouldn't be substituted back.)
All of that said, what are you doing that requires very long paths? Perhaps you could make your life easier by reevaluating what you're doing and avoiding long paths. Chances are, you [don't need paths that long anyway](http://www.codinghorror.com/blog/2006/11/filesystem-paths-how-long-is-too-long.html).
>
In the Windows API (with some exceptions discussed in the [linked document]), the maximum length for a path is `MAX_PATH`, which is defined as 260 characters.
(There is additionally a `NULL` termination character appended to the path, giving us 259 usable characters.)
Because Explorer (and almost all other Windows apps) rely on the Win32 API for filesystem access, it's not *practical* to get around this limitation even though it is *possible*:
>
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. Par exemple, "\\?\D:\very long path".
Malheureusement, you can't just type `\\?\D:\very long path` in to an Explorer window. The application must be designed to take advantage of these APIs and handle very long path names.
One way to access extended-length paths under Windows is to install [Cygwin](http://www.cygwin.com), a *nix emulation layer for Windows. In my testing, Cygwin does not appear to be limited by `MAX_PATH`; bash and vi had no problems with paths 2,000 characters long.
Gardez à l'esprit that even though vous pouvez utiliser bash to browse extended-length paths, you probably won't be able to open files in those paths in regular Windows applications. Par exemple, typing `notepad` while the working directory is an extended-length path gets you
>
Error: Current working directory has a path longer than allowed for a Win32 working directory. Can't start native Windows application à partir de là.
And trying `notepad "\\?\D:\very long path\file.txt"` doesn't work either; it launches, but just says
"Can't find file ..." Trying the same with [Notepad++](http://notepad-plus-plus.org/) crashes it. (Probably a buffer overflow.)
Your other option to access specific files buried deep within an extended-length path is to *shorten the path itself* by creating a NTFS [junction point](http://en.wikipedia.org/wiki/NTFS_junction_point). From an elevated invite de commandes:
```
D:\> mklink /J jct "\\?\D:\very\long\path"
```
Vous pouvez now access the contents of `D:\very\long\path\` from `D:\jct\`. You won't hit any path length problems because as far as Explorer and other apps are concerned, the path is just `D:\jct\` (or whatever). The NTFS driver handles redirecting the path (the "reparse point") transparently.
The downside to this approach is obviously that vous devez create a junction near the file you want to access; you still can't simply browse the entire directory structure.
Regarding special characters (`" * : < > ? \ |`), that's simply a no-go. Those characters have special meanings within Windows, so it's not possible to use them within paths. (Cygwin allows you to create files with special characters, but it does so by [substituting the characters](http://www.cygwin.com/cygwin-ug-net/using-specialnames.html) with special Unicode characters, which it then substitutes back when reading. Viewing these Cygwin-created files under Linux or in Explorer wouldn't look right, since the Unicode characters wouldn't be substituted back.)
All of that said, what are you doing that requires very long paths? Perhaps you could make your life easier by reevaluating what you're doing and avoiding long paths. Chances are, you [don't need paths that long anyway](http://www.codinghorror.com/blog/2006/11/filesystem-paths-how-long-is-too-long.html).