Why does the 260 character path length limit exist in Windows?

Question

I have come up against this problem a few times at inopportune moments:

Trying to work on open source Java projects with deep paths
Storing deep Fitnesse wiki trees in source control
An error trying to use Bazaar to import my source control tree

Why does this limit exist?

Why hasn't it been removed yet?

How do you cope with the path limit? And no, switching to Linux or Mac OS X is not a valid answer to this question ;)

@Artelius: Actually, Windows (at least from Win2K onwards) does support junction points (http://en.wikipedia.org/wiki/NTFS_junction_point), and Vista onwards support NT Symbolic links (http://en.wikipedia.org/wiki/NTFS_symbolic_link). Anyway, while symlinks can help make longer/nested paths more friendly, I can't think how symlinks would help if you're hitting path length limits. — Ashutosh Mehra, Dec 10 '09 at 11:29
On my Windows 8 PC the limit appears to be roughly 1024 characters, so YMMV. — William Jockusch, May 31 '14 at 18:04
Even if this limit did not exist, there are always lots of other limits, and every one of them could be annoying at some point. The point is why is this limit so low? After the era of 8.3, and with mega/giga sized hardware, a path should now be a dynamically allocated string with a virtually unlimited size. — Roland, Aug 25 '14 at 09:58
Coping: the windows error messages could be better. I just got the error "cannot find file..." (twice) when trying to open an Excel spreadsheet in a long directory after unpacking a zip in my Downloads directory. The error should rather be about trying to use a path exceeding MAX_PATH, or should be showing a truncated file name instead of the entire too-long name. — Roland, Aug 25 '14 at 10:04
Microsoft is finally addressing this problem, in Windows 10 Build 14352. — Warren P, May 30 '16 at 11:29
@WarrenP You mean this? http://stackoverflow.com/q/27680647/1157054 — Ajedi32, Jun 13 '16 at 17:52
Yes, and it looks like you have to modify the app manifest to make it long path aware. — Warren P, Jun 13 '16 at 21:03
@PatrickSzalapski unfortunately it was fixed https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2156195-fix-260-character-file-name-length-limitation?tracking_code=32c8b19e00e95981623c3b65db8f21e9 — phuclv, Apr 12 '17 at 17:16
with the \\?\ prefix we could already use 32k length paths, probably since NT3.5 — v.oddou, Sep 27 '18 at 02:57
@WarrenP Unfortunately, Microsoft never updated the Windows Explorer UI App which is where the problem still exists today in 2022. — justdan23, Jul 07 '22 at 16:44
@v.oddou Using the \\?\ doesn't work either as the Windows Explorer App refactors it to remove it before calling the older WIN32 API it is using to enumerate folders or open files. — justdan23, Jul 07 '22 at 16:46

score 280 · Accepted Answer · edited Apr 18 '19 at 15:09

280

Quoting this article https://learn.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

Maximum Path Length Limitation

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string<NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

Now we see that it is 1+2+256+1 or [drive][:\][path][null] = 260. One could assume that 256 is a reasonable fixed string length from the DOS days. And going back to the DOS APIs we realize that the system tracked the current path per drive, and we have 26 (32 with symbols) maximum drives (and current directories).

The INT 0x21 AH=0x47 says “This function returns the path description without the drive letter and the initial backslash.” So we see that the system stores the CWD as a pair (drive, path) and you ask for the path by specifying the drive (1=A, 2=B, …), if you specify a 0 then it assumes the path for the drive returned by INT 0x21 AH=0x15 AL=0x19. So now we know why it is 260 and not 256, because those 4 bytes are not stored in the path string.

Why a 256 byte path string, because 640K is enough RAM.

edited Apr 18 '19 at 15:09

John Cummings

1,949
3
22
38

answered Dec 10 '09 at 11:45

valli

5,797
2
19
9

29

The Windows API limits the length, even in the latest OS. Microsoft is afraid to break hundreds of millions of operating systems in use today if this were to change because they don't have geniuses working for them anymore that understand the API inside and out, like they did in the 1980s and 1990s. The risk is not worth changing it. http://serverfault.com/questions/163419/window-256-characters-path-name-limitation – JustBeingHelpful Jul 16 '14 at 21:40
2

... it's the same reason they store 64 bit drivers in the system32 folder, and store 32 bit drivers in the SysWOW64 folder. The risk of braking the original Windows API might put them into bankruptcy because their developers don't understand it well enough. – JustBeingHelpful Jul 16 '14 at 21:43
99

@MacGyver Sorry, but that's utter nonsense. Microsoft doesn't want to break the millions of poorly written applications out there that _assume_ things about the system that were never guaranteed. Unfortunately, things were the same way for so long that developers came to rely on them, so changing it now would break 3rd party applications and MS would get the blame. – Basic Aug 28 '14 at 09:36
31

btw there is no proof that Gates ever said the "640K Ram is enough for everyone" http://www.computerworld.com/article/2534312 – Patrick Nov 26 '14 at 15:34
16

@Basic The 260 character limit was **guaranteed** by Windows. The constant was declared as a *constant*, a structure was declared in the Windows header files that only has room for 260 characters. There is no way to change it. – Ian Boyd Jul 20 '15 at 13:59
6

@IanBoyd Constants can change between software versions (or even between builds). The reason to declare a constant is that it's a single point of reference. If all software checked on the constant as appropriate, then a change wouldn't be an issue. – Basic Jul 20 '15 at 17:59
44

@Basic The constant doesn't change once it's compiled into my application. I run an application which was last **built** in 1994, and still runs today in Windows 10. Microsoft promised a certain binary size of a block of memory, and the programmer followed that rule. If Microsoft were to change the constant, then *every existing application, who correctly followed the programming API, would be broken*. You cannot break binary compatibility. – Ian Boyd Jul 21 '15 at 14:12
6

A good insight into where the value 260 came from, but it doesn't actually answer the question. Why is the length of paths limited at all (other than by available memory in which to store the path)? Even if there was a limit under MS-DOS, why haven't MS been able to change the fact in this day and age? Even if it would break APIs that write the path into a char array of a fixed length, they could have introduced a new API that works in a more flexible way, and deprecated and later removed the old one. Or is the transition just still a work in progress? – Stewart Jan 21 '16 at 10:17
7

@IanBoyd There's a serious flaw in that argument - it doesn't explain why it couldn't be changed between Win16, Win32 and Win64. Of course, the Win16 implementation in Win32 OSs would need to raise an error in some way if the path is too long for the Win16 limit. Besides, binary compatibility has been broken a few times in the course of the history of Windows. For instance, Windows 95 can't run programs built for Windows 2. I get the impression that 64-bit versions of Windows can't run Win16 apps. – Stewart Jan 21 '16 at 11:40
12

@Stewart Binary compatibility broken between Win16 and Win32, yes. But Microsoft strove for complete *source code* compatibility between Win16 and Win32. FAT16, with it's maximum path of 255 characters, was what Windows 95 had to support; no point in increasing the constant to something larger than is valid (for the sole virtue of breaking existing applications). And Microsoft *did* create a new API that supports longer paths - for anyone who wants to use it (twenty-one years later people still refuse to use it) – Ian Boyd Jan 21 '16 at 15:32
2

@IanBoyd How does the use of the symbolic constants (`MAX_PATH` etc.) rather than hard-coding the numbers not achieve source code compatibility? – Stewart Jan 22 '16 at 19:44
6

@Stewart Because of programs that do `char szFilename[260]`. Under Windows 95, `MAX_PATH` larger than 260 was invalid (filesystem did not support value larger than 260). Lets ignore the fact that an application written for Windows 95 as `char szFilename[MAX_PATH]` will fail under Windows 2000. Lets forget binary app compat. Assume we are willing to tell users that none of their Win32 Windows 95 apps will work under Win32 Windows 2000. We are willing try for source code compatibility - *"you can simply recompile with updated headers"*. The above code, recompiled for 2000, will fail under 2000. – Ian Boyd Jan 24 '16 at 15:14
7

Why was there a limit for filesystem path lengths at all? Engineering tradeoffs. FAT16 had a limit. FAT32 had a limit. NTFS had a limit. ReFS had a limit. VFS had a limit. Every filesystem has a limit. In Windows 95, the longest path the filesystem (FAT16) could support was 256 characters. Specifying a `MAX_PATH` constant longer than the valid max path length of the filesystem is both wrong and stupid. – Ian Boyd Jan 24 '16 at 15:21
6

@IanBoyd Surely there are far more programs that rely on filenames being 8.3, or pointers being 2 bytes in size, or ints ranging from -32768 to 32767, than this? – Stewart Feb 10 '16 at 13:20
@Stewart Which is why any program upgrading to Windows 95 had to be recompiled for long filenames and 32-bit pointer. And, at the same time, had to be written to support a MAX_PATH of 260 characters - which was the maximum path that can possibly exist in the filesystem in Windows 95. – Ian Boyd Feb 10 '16 at 15:43
6

@IanBoyd Exactly. So recompiling programs that use this API so that they can handle longer pathnames is just the same. As such, it makes no sense that MS singled out this particular constant to decide not to change. – Stewart Feb 22 '16 at 13:17
@Stewart I think what you're missing is that the constant *didn't* change when Windows 95 came out. It would be wrong to change the constant to a larger value when existing value is correct. – Ian Boyd Feb 22 '16 at 14:33
3

[Bigger Directories](http://www.codeproject.com/Tips/1089681/Bigger-Directories) ought to be enough for anyone. -lmstearn – Laurie Stearn May 04 '16 at 11:57
1

They are removing the limitation in Windows 10 - Redstone. It will be a registry edit to remove the limitation and has the potential to break other apps but at least it's a start. – Jacob Roberts Jun 01 '16 at 19:57
2

The issues and possible solutions with file path length was discussed in a DotNetRocks episode. Well worth the listen: http://www.dotnetrocks.com/?show=1320 – Riaan Aug 12 '16 at 11:24
12

@Stewart And what is the OS supposed to do when your non-compliant program that worked fine on 95 stops working because *someone else* created a file that has a path longer than 260 characters? How do you explain to the user that file `MyDocument.doc` works fine but `My Extended Document.doc` doesn't, unless they move it to another directory where it suddenly starts working again? Stop pretending that it's a simple problem that should have been fixed a long time ago, it's much more complicated than just changing a constant. – Luaan Aug 23 '16 at 12:21
8

@Luaan And how do you explain this? Because this is exactly what happens today - path is not limited to 260 characters, you can easily create larger path, its jus0t functions that do not accept paths longer than 260 chars. – Mar 14 '18 at 12:38
2

You would have thought that they could have done a fudge in a similar way to what they did when moving from 8.3 file names to long file names. – Martin Brown Aug 02 '18 at 17:43

score 174 · Answer 2 · edited Mar 06 '23 at 10:51

174

This is not strictly true as the NTFS filesystem supports paths up to 32k characters. You can use the win32 api and "\\?\" prefix the path to use greater than 260 characters.

A detailed explanation of long path from the .Net BCL team blog.
A small excerpt highlights the issue with long paths

Another concern is inconsistent behavior that would result by exposing long path support. Long paths with the \\?\ prefix can be used in most of the file-related Windows APIs, but not all Windows APIs. For example, LoadLibrary, which maps a module into the address of the calling process, fails if the file name is longer than MAX_PATH. So this means MoveFile will let you move a DLL to a location such that its path is longer than 260 characters, but when you try to load the DLL, it would fail. There are similar examples throughout the Windows APIs; some workarounds exist, but they are on a case-by-case basis.

edited Mar 06 '23 at 10:51

Sk8erPeter

6,899
9
48
67

answered Dec 10 '09 at 11:52

softveda

10,858
6
42
50

5

Fair enough, but it means you have to use P/Invoke in a lot of places and this, to my mind, reduces the portability of your .Net code. What if I wanted to keep Mono-compatibility? – Jeffrey Cameron Dec 10 '09 at 22:50
2

My point was that you can use long path if you really wanted to. But I agree that it is a pain and personally I would avoid this as well. – softveda Dec 11 '09 at 02:12
9

This should be the chosen answer. Actually answers the question posed by user of WHY this limit exists AND provides a work-around. Upvote for visibility – KyleMit Mar 20 '13 at 21:06
3

It sounds to me that Microsoft needs to fix their APIs, and I guess this is not a priority. I was surprised that this limit still exists in Windows 8. – Mas May 15 '13 at 15:16
5

@Mas The "fix" you want was done all the back to Windows XP. Calling the unicode version of their API will allow you to access the "extended path". I believe explorer automatically handles this. Here is one such function that supports it - http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418(v=vs.85).aspx . – Natalie Adams Oct 16 '13 at 03:59
1

This answer doesn't actually answer the main question of "why 260?" It only addresses the secondary question of how to cope with it. I imagine that a lot of people would find their way to this page the same way I did: trying to find out why it's 260 (as opposed to 256). – Synetech Sep 15 '20 at 01:22
Although even using the UNC prefix, Windows Explorer does not support it and will change it to a normal path. In turn, Windows Explorer will convert the long path to a short path if the feature is enabled on the NTFS file system, but if the short path exceeds 260, Windows Explorer will not display the files or folders past that as existing. – justdan23 Jul 07 '22 at 16:30

score 151 · Answer 3 · edited Aug 07 '19 at 00:16

151

The question is why does the limitation still exist. Surely modern Windows can increase the side of MAX_PATH to allow longer paths. Why has the limitation not been removed?

The reason it cannot be removed is that Windows promised it would never change.

Through API contract, Windows has guaranteed all applications that the standard file APIs will never return a path longer than 260 characters.

Consider the following correct code:

WIN32_FIND_DATA findData;

FindFirstFile("C:\Contoso\*", ref findData);

Windows guaranteed my program that it would populate my WIN32_FIND_DATA structure:

WIN32_FIND_DATA {
   DWORD    dwFileAttributes;
   FILETIME ftCreationTime;
   FILETIME ftLastAccessTime;
   FILETIME ftLastWriteTime;
   //...
   TCHAR    cFileName[MAX_PATH];
   //..
}

My application didn't declare the value of the constant MAX_PATH, the Windows API did. My application used that defined value.

My structure is correctly defined, and only allocates 592 bytes total. That means that i am only able to receive a filename that is less than 260 characters. Windows promised me that if i wrote my application correctly, my application would continue to work in the future.

If Windows were to allow filenames longer than 260 characters then my existing application (which used the correct API correctly) would fail.

For anyone calling for Microsoft to change the MAX_PATH constant, they first need to ensure that no existing application fails. For example, i still own and use a Windows application that was written to run on Windows 3.11. It still runs on 64-bit Windows 10. That is what backwards compatibility gets you.

Microsoft did create a way to use the full 32,768 path names; but they had to create a new API contract to do it. For one, you should use the Shell API to enumerate files (as not all files exist on a hard drive or network share).

But they also have to not break existing user applications. The vast majority of applications do not use the shell api for file work. Everyone just calls FindFirstFile/FindNextFile and calls it a day.

edited Aug 07 '19 at 00:16

Jonathan Potter

36,172
4
64
79

answered Jun 30 '15 at 15:47

Ian Boyd

246,734
253
869
1,219

1

Could Windows not transparently translate long paths to shorter ones as a backwards-compatibility shim? I believe Windows 9x did something like that for DOS compatibility. – Josiah Keller Aug 10 '15 at 20:25
5

@JosiahKeller If it did, it would break the contract originally defined for that method, and doing that could overwrite unintended memory, and prtentially open a security hole. The only way to fix this is to offer a new improved API (like the Unicode aware variants), and *hope* everyone recompiles/rereleases all their applications using the newer API. – Rowland Shaw Oct 19 '15 at 11:22
@RowlandShaw Fortunately Microsoft **did** create a new API that supports long filenames. – Ian Boyd Oct 19 '15 at 14:34
1

@RowlandShaw Hence I said "transparently." It should still fit the original contract. Like I said, it would not be unprecedented. – Josiah Keller Oct 19 '15 at 14:58
2

Microsoft just needs to hurry up and make there Linux Distro... I will switch immediately and be done with the old crumpled up windows API. – Ryan Mann Nov 21 '15 at 19:15
2

@Ryios I don't think my existing Windows applications will run on Linux. – Ian Boyd Nov 22 '15 at 16:38
22

Backward compatibility is nice. But I think avoiding such (often really nasty) problems today is more important than supporting Windows 3.1 applications. How many people encounter problems with to long paths? And how many people do still use Windows 3.1 applications? They even canceld support for Windows XP. So why don't they just make an annoucement, that from Windows [x] and later applications which assume there won't be a path longer than 260 characters, will not work as expected when they ancounter a path which is to long? Our speed limits also don't regard carriages. – JuSchu Jun 12 '16 at 18:36
2

@JuSchu It's not just Windows 3.1 applications. Applications written today using the correct API will not function. – Ian Boyd Jun 13 '16 at 00:34
Applications written against Windows XP (or Win 7) at that time would not run on later versions. OR WORSE, would run until they hit a path that was too long, and then fail with all manner of mysterious errors due to memory becoming overwritten. – quickly_now Oct 07 '16 at 05:13
1

Could you show me the place where Windows PROMISED you anything? I have never seen Microsoft promising backward compatibility forever for anything. I don't believe that any Win3.11 application runs under 64Bit Windows 10 because it doesn't have a 16Bit subsystem. DOSBox and similar tools don't matter. – The incredible Jan May 04 '17 at 09:14
4

@TheincredibleJan MSDN. [Documentation creates contract, which is why you need to be very careful what you document](https://blogs.msdn.microsoft.com/oldnewthing/20150508-00/?p=44904). – Ian Boyd May 10 '17 at 15:01
3

This answer confuses the max path *component* length, which is typically 255 characters for MS filesystems and *completely fixed*, with the max *path* length, which can be up to about 32,760 characters in NT due to the kernel's `UNICODE_STRING` structure. With the "\\?\" prefix, all of the common file systems such as NTFS, UDF, FAT32, and exFAT support the full NT max path length. The 260-character path limit is due to fixed buffers in the runtime library for DOS/Windows path processing (e.g. ANSI <=> Unicode, working directory, and DOS<=>NT path conversion). – Eryk Sun Sep 08 '17 at 23:50
1

And I cannot even fathom the wisdom of the ingenious Windows developers, who came up with _promises_ for backward compatibility, yet lacking _forward compatibility_. **Awesome.** – Константин Ван Jan 10 '19 at 14:30
1

@КонстантинВан It's 1984, and computers have 512 KB of memory. Filenames are 12 characters long and there is no such thing as folders. Here's the [WIN32_FIND_DATA](https://learn.microsoft.com/en-us/windows/desktop/api/minwinbase/ns-minwinbase-_win32_find_dataa) structure that allows up to 128 characters for a filename (when we only need 12). And years later, to support OS/2 long filenames, the `MAX_PATH` is increased to 260. How would you define the `WIN32_FIND_DATA` structure to allow forward compatibility? – Ian Boyd Jan 10 '19 at 15:18
2

@IanBoyd A _variable-length array_, which don't take 128 bytes to store a string of less than 16 bytes. – Константин Ван Jan 10 '19 at 18:21
4

@КонстантинВан With that solution the caller needs to know how much memory to allocate for the FIND_DATA structure before they can call the function? That's not good for code size. Now one function call becomes two, and in the loop of finding all files, i've just made everything 50% slower. On my 4.77MHz machine that's no good. You've made things 50% slower for nothing. And i have to call this every time, and reallocate memory every time? That's no good. Presumably you'd have this variable length array at the end of hte structure, othersize i have to do math to read the subsequent fields. – Ian Boyd Jan 10 '19 at 20:21
But you can't push your variable-length array to the end, because then you have **AlternateName** field member, which would also have to be at the end? They can't both be at the end. Also, why am i allocating memory on the fly; i want to put the fixed amount of data in the fixed block. – Ian Boyd Jan 10 '19 at 20:23
2

@IanBoyd Look, there's what's supposed to be _promised_ and what's not. What's not is breaking forward-compatibility and saying it's okay, making excuses out of irresponsibility against future users. Forward-compatibility is necessary for a system to be used in the future, no matter what. And for an operating system to be future-ready, it should assume near-infinite resources and inputs given; – Константин Ван Jan 10 '19 at 21:22
1

@IanBoyd ― which means, for paths, it's future-ready and worth being _promised_ when there's no `MAX_PATH` at all but `OS2_MAX_PATH`. What they should've done is “The lengths of paths are limitless, but for now there's a practical limit for technical reasons, so we provide you a means to distinguish future-supported paths.” so as for us to use variable-length, limitless paths, powered by modern processors, in Windows 10 nowadays. When will they learn “`long`” cannot be forever “`long`,” “`short`” cannot be forever “`short`?” – Константин Ван Jan 10 '19 at 21:23
1

@IanBoyd: There are multiple ways they could make it variable-length: have the user pass two pointers for cFileName and AlternateName resp., have the system allocate the strings on the process heap, or redesign the API to act like a CreateFile/ReadFile -- that would have enormous performance benefits for applications iterating over huge directories. Sure, I understand their position at the time and why they didn't do any of these. Side note: `GetFullPathName` *does* support long paths *without* `\\?\` prefix even as back as XP, undocumented. It can do so cause it returns the needed buffer size – Yakov Galka Feb 01 '19 at 15:58
1

*"I understand why they didn't do any of these"*. And now you understand backwards-compatibility. – Ian Boyd Feb 01 '19 at 16:10
1

This answer and discussion are both non-sequitur to the issue of the path length. That someone at Microsoft (who was more than a bit clueless) happened to reuse `MAX_PATH` in the definition of `WIN32_FIND_DATA` for *filename length*, instead of the proper macro constant `MAXIMUM_FILENAME_LENGTH` (256), has no bearing on ABI compatibility for programs that use this data structure. Surely they'd just fix the definition in the API, using a new macro name with a value of 260, such as `LEGACY_MAX_PATH`. Silly mistake resolved. – Eryk Sun Aug 02 '19 at 12:26
3

Backwards compatibility is more than just 'nice'. It resulted in Microsoft becoming one of the largest businesses on the planet. – Steve Kidd Nov 06 '20 at 15:04
Decent description of just this [from Microsoft as it declined the feature request](https://web.archive.org/web/20141024182243/http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2156195-fix-260-character-file-name-length-limitation) (with 2,999 votes) to allow Visual Studio to use more than 260: "_fixing it requires a large and complicated architectural change across different products and features... if we removed this limitation from our first party tools it will still likely exist elsewhere in Visual Studio’s ecosystem of extensions and tools_" – ruffin Nov 17 '22 at 14:51
I'm curious which Windows 3.11 application you're using, @IanBoyd – Alex Szatmary Aug 30 '23 at 18:37
1

@AlexSzatmary [MathCAD 3.1](https://winworldpc.com/product/mathcad/3x). It was a 32-bit application that ran under Windows 3.1, but only because Microsoft had created [Win32s](https://en.wikipedia.org/wiki/Win32s) which allowed you to run the 32-bit WinAPI on 16-bit Windows 3.1. – Ian Boyd Aug 31 '23 at 19:35

score 78 · Answer 4 · edited Feb 04 '22 at 18:24

78

From Windows 10. you can remove the limitation by modifying a registry key.

Tip Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.

A registry key allows you to enable or disable the new long path behavior. To enable long path behavior set the registry key at HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD). The key's value will be cached by the system (per process) after the first call to an affected Win32 file or directory function (list follows). The registry key will not be reloaded during the lifetime of the process. In order for all apps on the system to recognize the value of the key, a reboot might be required because some processes may have started before the key was set. The registry key can also be controlled via Group Policy at Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. You can also enable the new long path behavior per app via the manifest:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

edited Feb 04 '22 at 18:24

riQQ

9,878
7
49
66

answered Oct 28 '16 at 12:49

Root Loop

3,004
9
46
72

31

Sadly even in the latest version Win10, the File Explorer itself still has problem dealing with long path name. Even "Copy as Path" in the context menu doesn't work as expected; it only copy the first 260 chars. You can't create folder, copy/move/open file... Make me wonder what is the point of this change. – raymai97 Jun 29 '17 at 07:43
1

Note that the claim that the system setting is independent from the manifest setting is wrong. Both are required. The policy has to be enabled at the system level and the manifest has to declare that the application is long-path aware. – Eryk Sun Aug 02 '19 at 11:33
I read that making this change could cause compatibility issues with older 32-bit applications, but is this type of problem with compatibility common? I'd like to make the change myself. https://lifehacker.com/windows-10-allows-file-names-longer-than-260-characters-1785201032 – KDP Feb 07 '20 at 14:44
2

@KDP, it creates a compatibility problem with most 32-bit programs, a lot of 64-bit programs, and any other devices that aren't able to handle longer filenames (i.e., you wouldn't be able to transfer files to/from most memory-cards, flash-drives, media-servers/NAS, routers, older computers, printers, etc…) – Synetech Sep 15 '20 at 01:26
@Synetech Things aren't that bad, because first of all the manifest controls if ONE concrete app is able to use longer paths or not at all. Second, to get a problem, you need longer paths for an app which doesn't support those anyway. It's pretty unlikely to have long, incompatible paths on some storage in the first place and AFTERWARDS using an incompatible app with those paths afterwards. Why should one do soß How did the files end up there at all etc.? – Thorsten Schöning Apr 30 '21 at 16:22
@raymai97 Windows Explorer is special, it uses its own concepts of handling paths and needs to keep arbitrary additional plugins in mind. So by enabling this feature for Windows Explorer, it might be enabled for arbitrary other plugins as well or those might receive unexpected long paths themself and that might simply be too risky right now. – Thorsten Schöning Apr 30 '21 at 16:27
1

Even with the registry key 'LongPathsEnabled' turned on in the Registry. The Windows Explorer application is hard coded with the 260 Character Limit on the Folder Path to Browse. When the limit is reached, Windows Explorer will attempt to rewrite the path using the short names (with tilda characters) if the NTFS disk is turned on to support short names (e.g. using dir /x shows the short names next to folders longer than 8.3 characters) and will still fail to display, open, or sometimes read even security settings from within the Windows Explorer App when the path exceeds 260 again. – justdan23 Jul 07 '22 at 16:05

score 35 · Answer 5 · edited Jun 19 '15 at 07:54

35

You can mount a folder as a drive. From the command line, if you have a path C:\path\to\long\folder you can map it to drive letter X: using:

subst x: \path\to\long\folder

edited Jun 19 '15 at 07:54

BaCaRoZzo

7,502
6
51
82

answered Dec 10 '09 at 11:56

jonchang

1,434
9
13

i am receiving "Invalid paramter j:" when attempting this command – barrypicker Aug 09 '13 at 18:53
This needs to be run from an Administrator (elevated) command prompt. – Mrchief Jun 27 '14 at 14:46
This will fail with forward slashes, needs to be backslashes. – cchamberlain May 22 '15 at 22:36
1

I am not sure if this applies to windows 10 only, however I just found that when trying to run this command, if I run as an administrator as suggested above the drive does not appear to be available. This is because the behaviour appears to be similar to mapping a network drive and is session specific etc, so when I ran as an administrator and used this command, that session could use x: TL;DR If you can't see the drive try running the command without being in administrator mode. – Jaddie Sep 14 '15 at 18:48
3

`subst` is local-session/account - see https://superuser.com/questions/29072/how-to-make-subst-mapping-persistent-across-reboots/29079#29079 for how to make it 'system wide' – user2864740 Mar 01 '19 at 19:23
subst.exe wraps WINAPI `DefineDosDeviceW`. This API can target a path of up to about 4K characters, which is about the same as a filesystem junction mountpoint or symbolic link. It creates an object-namespace symlink in the user's local device mountpoint directory (i.e. "\\?\"). For the SYSTEM logon session, this is the "\Global??" directory. For all other logons, it's "\Sessions\0\DosDevices\". Because it's per-logon, this is a problem for a split token, since the linked administrator and standard tokens use separate logon sessions. So a filesystem junction is simpler. – Eryk Sun Aug 02 '19 at 11:49
You can use 'net use' to map a drive and use this to like @BaCaRoZzo mentioned: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/gg651155(v=ws.11) – justdan23 Jul 07 '22 at 16:10

score 20 · Answer 6 · edited Jun 19 '15 at 07:54

20

One way to cope with the path limit is to shorten path entries with symbolic links.

For example:

create a C:\p directory to keep short links to long paths
mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
add C:\p\foo to your path instead of the long path

edited Jun 19 '15 at 07:54

BaCaRoZzo

7,502
6
51
82

answered Aug 01 '14 at 21:51

JDiMatteo

12,022
5
54
65

4

Didn't have to create the directory first, so step 1 is not necessary. – ohaal Feb 18 '15 at 13:34
4

This trick doesn't always work as many application try to resolve the links – nponeccop Jan 03 '18 at 19:54
4

The `/j` option creates a junction mountpoint for a local volume device or a path on a local volume (like a Unix bind mount). It does not create a symbolic link. It's an important distinction since junction mountpoints are always evaluated on a server and must target local devices, while symbolic links are evaluated on the client and may target remote paths (if allowed by policy). Like a subst.exe drive (i.e. `DefineDosDeviceW`), a junction target is typically limited to about 4K characters. It's actually 8K characters, split about evenly between the substitute path and the display path. – Eryk Sun Aug 02 '19 at 11:57
1

A Junction is a Hard Link. Junctions can only be made from the command line. There is no UI controls in the OS to create them. However, be aware of the dangers of using Hard Links as they can cause circular loops if someone tries to copy files that Hard Link back to their parent folder. I lost a hard drive once because someone created a Hard Link back to root so when someone recursively deleted a folder, it cycled back and deleted the whole hard drive. – justdan23 Jul 07 '22 at 16:14
@justdan23 interesting exploit! Is there a way to forbid hard links in a system? – Satoshi Nakamoto Feb 19 '23 at 22:13

score 16 · Answer 7 · edited Nov 22 '21 at 22:47

16

You can enable long path names using PowerShell:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Type DWord -Value 1

Another version is to use a Group Policy in Computer Configuration/Administrative Templates/System/Filesystem:

edited Nov 22 '21 at 22:47

Peter Mortensen

30,738
21
105
131

answered Aug 23 '18 at 11:13

MovGP0

7,267
3
49
42

7

Each application still has to declare that it's long-path aware. Microsoft has done a poor job communicating this by making it seem like the application manifest is just *another* way to enable this feature, rather than clearly explaining that it's a contract between the OS (system level policy) and application in which both have to agree. – Eryk Sun Aug 02 '19 at 12:09
1

Even Visual Studio 2019 Community doesn't support long paths, sadly – Pieterjan Sep 26 '20 at 22:23
Even Windows Explorer doesn't support long path names either. It fakes it by using the short names when the path exceeds 260, but once you hit the 260 limit, you cannot see any folders or files below using the Windows Explorer app. You can access them from other apps written to support 32767 paths and also the command line, but not the UI of the Windows Explorer app. I am surprised in 2022 this is still an issue, but I heard Microsoft is working on pushing out a patch in Windows 10 and their new servers to support trying to fix it. – justdan23 Jul 07 '22 at 16:17
The use of the MAX_PATH macro didn't age well – Davide_24 Mar 21 '23 at 20:08

score 11 · Answer 8 · answered Dec 19 '14 at 15:02

11

As to why this still exists - MS doesn't consider it a priority, and values backwards compatibility over advancing their OS (at least in this instance).

A workaround I use is to use the "short names" for the directories in the path, instead of their standard, human-readable versions. So e.g. for C:\Program Files\ I would use C:\PROGRA~1\ You can find the short name equivalents using dir /x.

answered Dec 19 '14 at 15:02

Conrad

2,197
28
53

2

Short path names can be disabled in the registry (or was it the filesystem itself?), so this really isn't a dependable workaround. – rubenvb Dec 02 '17 at 13:03
7

@rubenvb I'm sure most if not all Windows features can be disabled in the registry so ¯\\_(ツ)_/¯ – Conrad Dec 02 '17 at 20:02
1

Generating short names can be disabled for NTFS (and should be because it's inefficient in many cases), either for the whole system or per volume, so it is an unreliable approach even for paths on the system drive, which must be NTFS. It's possible to manually set short names on files and directories in NTFS, but this doesn't extend to newer filesystems that do not support short names at all, such as exFAT and ReFS. Short names should be considered a deprecated feature that's retained for compatibility in limited cases, like the old ANSI/OEM API using single- and double-byte codepages. – Eryk Sun Aug 02 '19 at 12:05
1

@eryksun Please see my previous comment about disabling short path names. :) Just because you think it should be considered deprecated, doesn't mean it actually is. MS has no plans to deprecate this feature. (Also, why are you installing Windows software on exFAT/ReFS partitions?) – Conrad Aug 02 '19 at 16:00
I still say to just use non-normalized device paths (i.e. "\\?\" prefix), since they're always available and obvious. For example, translate `PATH` and pass it to `SearchPathW`. It's efficient, too, since the runtime library creates "\\?\" device paths for NT anyway. As to newer filesystems, we probably wouldn't see software installed on an exFAT volume, other than portable applications, since it has no security, but I wouldn't rule out ReFS. Users install programs in non-standard locations for reasons of convenience, space, or performance. – Eryk Sun Aug 02 '19 at 18:05

score 10 · Answer 9 · edited Mar 20 '17 at 10:18

As to how to cope with the path size limitation on Windows - using 7zip to pack (and unpack) your path-length sensitive files seems like a viable workaround. I've used it to transport several IDE installations (those Eclipse plugin paths, yikes!) and piles of autogenerated documentation and haven't had a single problem so far.

Not really sure how it evades the 260 char limit set by Windows (from a technical PoV), but hey, it works!

More details on their SourceForge page here:

"NTFS can actually support pathnames up to 32,000 characters in length."

7-zip also support such long names.

But it's disabled in SFX code. Some users don't like long paths, since they don't understand how to work with them. That is why I have disabled it in SFX code.

and release notes:

9.32 alpha 2013-12-01

Improved support for file pathnames longer than 260 characters.

4.44 beta 2007-01-20

7-Zip now supports file pathnames longer than 260 characters.

IMPORTANT NOTE: For this to work properly, you'll need to specify the destination path in the 7zip "Extract" dialog directly, rather than dragging & dropping the files into the intended folder. Otherwise the "Temp" folder will be used as an interim cache and you'll bounce into the same 260 char limitation once Windows Explorer starts moving the files to their "final resting place". See the replies to this question for more information.

I was wrong, 7zip and WinRAR do extract all the folders and files. It's just that the property of a folder in Windows only reports the number of folder and files that don't violate the limitation. It's as if that Windows Explorer doesn't dig any deeper to discover folders when the max path is reached. — Twisted Whisper, Oct 01 '15 at 17:57
It is possible to _delete_ a long path in 7-zip with shift-del. — Laurie Stearn, May 04 '16 at 11:51
Short answer - use 7zip to unzip a .zip file....worked for me on Windows 7 — andrewcockerham, Dec 02 '16 at 03:05
Beware of 7zip as the latest version in 2022 successfully zipped a WIM file, but failed to restore a WIM file properly. DISM restored the WIM file properly when created by 7zip. Something to be aware of. Use the \\?\ prefix in front of all drive letter paths to trigger 7zip to work with 32,767 length paths to ZIP or WIM up. — justdan23, Jul 07 '22 at 16:36

score 8 · Answer 10 · edited Dec 08 '18 at 05:32

8

It does, and it is a default for some reason, but you could easily override it with this registry key:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

See: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

edited Dec 08 '18 at 05:32

shA.t

16,580
5
54
111

answered May 14 '18 at 19:53

Sergey Dryganets

899
8
18

score 3 · Answer 11 · answered Dec 02 '17 at 12:58

3

Another way to cope with it is to use Cygwin, depending on what do you want to do with the files (i.e. if Cygwin commands suit your needs)

For example it allows to copy, move or rename files that even Windows Explorer can't. Or of course deal with the contents of them like md5sum, grep, gzip, etc.

Also for programs that you are coding, you could link them to the Cygwin DLL and it would enable them to use long paths (I haven't tested this though)

answered Dec 02 '17 at 12:58

eliblanco87

90
7

1

How does it avoid the limit? Isn't it dependent on the underlying file system (not a rhetorical question)? Did you test it? Do you have a reference you could add to your answer? (But ***without*** "Edit:", "Update:", or similar - the answer should appear as if it was written today.) – Peter Mortensen Nov 22 '21 at 22:48
The Windows Command Line does support 32,767 path lengths. The issue is for legacy apps using the older WIN32 API which only supports a hard coded, compiled in limit of 260 characters. The Windows Explorer UI Application is the issue. It still uses the old WIN32 API and doesn't support overriding the PATH to use an UNC PATH. While the UI takes a UNC PATH, it will refactor it after you hit the enter key and change it back and then fail on long paths (even after refactoring to short names if enabled). I tried it. – justdan23 Jul 07 '22 at 16:40

Why does the 260 character path length limit exist in Windows?

11 Answers11

9.32 alpha 2013-12-01

4.44 beta 2007-01-20

Linked

Related