exceeding max_path (path length > 260 characters)

[Start Me Up]

Hello,

as you are probably aware, Windows has problems with long paths (total length > 260 characters).

---

In old Windows versions there is the "\\?\"-trick, which helps in a few situations:

Quote

The "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send ... it straight to the file system. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs.

... it turns off automatic expansion of the path string ... but not all file I/O APIs support "\\?\" ... Unicode APIs should be used ...

---

Starting with Windows 10, it is possible to allow specific applications to use longer paths.

According to the documentation, Microsoft modified specific functions of the API to allow using longer paths for specific applications in Windows 10. So the list of functions is rather interesting. And here it is:

• CopyFileW
• CopyFile2
• CopyFileExW
• CreateDirectoryW
• CreateDirectoryExW
• CreateFileW
• CreateFile2
• CreateHardLinkW
• CreateSymbolicLinkW
• DeleteFileW
• FindFirstFileNameW
• FindFirstFileW
• FindFirstFileExW
• FindFirstStreamW
• FindNextFileNameW
• FindNextFileW
• FindNextStreamW
• GetCompressedFileSizeW
• GetCurrentDirectoryW
• GetFileAttributesW
• GetFileAttributesExW
• GetFinalPathNameByHandleW
• SetFileAttributesW
• GetFullPathNameW
• GetLongPathNameW
• MoveFileW
• MoveFileExW
• MoveFileWithProgressW
• RemoveDirectoryW
• ReplaceFileW
• SearchPathW
• SetCurrentDirectoryW

---

Is anyone aware of any pioneer work that has been done to improve the situation with Windows versions older than Windows 10?

Edited Monday at 05:59 AM by Start Me Up

[jumper]

For FAT and NTFS drives, API wrappers could walk the path string and shorten each long folder or file name as needed. Network shares to other file systems could be a problem.  Temporary environment variables and drive mappings might also be possible.

I've considered these possibilities for KernelEx should the need arise, but haven't done any tests. For years I have been successfully using a function I wrote to walk a path string and lengthen each short folder or file name. Doing the opposite should be easy.

 

[Start Me Up]

On 12/19/2025 at 2:28 AM, jumper said:

For FAT and NTFS drives, API wrappers could walk the path string and shorten each long folder or file name as needed.

The restriction you addressed in the FAT32 file system and the NTFS file system is probably the most difficult part to solve. Since these 2 file systems allow no object names (folder names or file names) longer than 256 characters, it will be a problem storing longer names if the file system driver prevents it. Your suggested solution to shorten long object names leads to truncated names and looses the uniqueness of the names. Once a name is shortened the truncated part is lost and we might have 2 folders or 2 files with the same name.

---

There is an easier part where at least some progress can be achieved:

Some of the functions restrict the caller to max_path for the total path name (not the object name), even though there doesn't seem to be a good reason. So it might be the case, that these restrictions can be lifted.

However, some functions return a path and the caller might provide a buffer, that can take no more than max_path characters. These functions are more problematic, because we don't want to create buffer overruns.

Here is the list of functions, which don't return paths:

• CopyFile2
• CopyFileExW
• CopyFileW
• CreateDirectoryExW
• CreateDirectoryW
• CreateFile2
• CreateFileExW
• CreateFileW
• CreateHardLinkW
• CreateSymbolicLinkW
• DeleteFileW
• GetCompressedFileSizeW
• GetFileAttributesExW
• GetFileAttributesW
• GetFullPathNameW
• GetLongPathNameW
• MoveFileExW
• MoveFileW
• MoveFileWithProgressW
• RemoveDirectoryW
• ReplaceFileW
• SetCurrentDirectoryW
• SetFileAttributesW

 

Here is the list of functions, which return paths:

• FindFirstFileExW
• FindFirstFileNameW
• FindFirstFileW
• FindFirstStreamW
• FindNextFileNameW
• FindNextFileW
• FindNextStreamW
• GetCurrentDirectoryW
• GetFinalPathNameByHandleW
• SearchPathW

---

Quote

I've considered these possibilities for KernelEx

Well, if you are talking about KernelEx for Windows 98 and Windows Millenium, we might also consider looking into the slim-character versions of the functions (for example RemoveDirectoryA) and not just the wide-character versions (for example RemoveDirectoryW). I don't know a good reason, why long paths should be limited to a specific character set used.

Edited 3 hours ago by Start Me Up

[user57]

programming-wise normal strings get translated to the unicode string (windows do so internal with its deeper function)

https://learn.microsoft.com/en-us/windows/win32/api/ntdef/ns-ntdef-_unicode_string

theoretical these can have a bigger value of 260 - max_path has not 256 for a reason of terminating 0´s 

 

an example would be CreateFileA/W

this one gets translated to ZwCreateFile(NtCreateFile)

to create this unicode string there is :

RtlInitUnicodeString( &fileNameUnicodeString, L"\\Device\\Harddisk0");

and then:
InitializeObjectAttributes( &objectAttributes, &fileNameUnicodeString, OBJ_CASE_INSENSITIVE, NULL, NULL );

then it looks something like:
ZwCreateFile( &hFileHandle, SYNCHRONIZE|FILE_ANY_ACCESS,
&objectAttributes,
&IoStatus,
NULL,
0,
FILE_SHARE_READ|FILE_SHARE_WRITE,
FILE_OPEN,
FILE_NON_DIRECTORY_FILE,
NULL,
0);

 

explaining that unicode-string:

typedef struct _UNICODE_STRING

{ USHORT Length; USHORT MaximumLength; PWSTR Buffer; } UNICODE_STRING, *PUNICODE_STRING;

 

this one got a buffer and a Length and MaximumLength - ushort is 65535 in size

but that are theorecial numbers 

it raise questions to make so many folders so they extend the length of 256 signs

[NotHereToPlayGames]

1 hour ago, user57 said:

it raise questions to make so many folders so they extend the length of 256 signs

That's one thing I never liked about XP's default setup.

Something like "C:\Documents and Settings\YourName\My Documents" might not seem like much at first, but those 47 characters is using up 18% of your allotted 256.

The thing that always annoyed me is that Windows would run everything just fine, even if you exceed 256, *UNTIL* you go to copy/archive the files and only then does Windows throws up a name-too-long error.

Even though it's been using those names as-is without any issues.