Path length limit of (I think) 260 characters

[PhilippGrasboeckDynatrace]

I really like winfile due to it's responsiveness.
Is there any chance to get rid of the fixed max length of 260 characters for the path length?
If so, then winfile would be truly superior to Windows Explorer, which has the same problem.

[daniel-white]

i think many of the win32 api calls have that limit, so its a limitation of win32.

[My1]

but there are ways around it. total commander for example can show that easily.

[ZanderBrown]

Windows 10 has long path mode, otherwise your pretty stuck for Win32

[My1]

w10 isnt even needed.

[ZanderBrown]

Yes but Total Commander likely isn't using native Win32

[My1]

apparently there has already been a not too-bad way before:
https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath

"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"."

let me note that I grabbed this link from here:

https://stackoverflow.com/a/1066022/4426048

which is an answer from 2009

[PhilippGrasboeckDynatrace]

I am aware of the MAX_PATH win32 api limitation.
However, Windows recently "solved" this by offering an opt-in registry setting "LongPathsEnabled".
In winfile, the limit is still in place - so my question is: can winfile be retrofitted to handle long paths ?

[malxau]

I think there are three issues here that need to be kept separate.

1. Winfile, like many legacy codebases, uses fixed sized "worst case" string lengths and does things like put them on the stack. In order to support huge lengths, this type of thinking needs to go away and be replaced by fully dynamic allocations for all file names. As of this writing, there are 182 instances of "MAXPATHLEN" in *.c files. Until this is done there's not much point talking about APIs to send huge strings to, because there's no huge strings to send.
2. The Windows 10 API support is opt-in via manifest, but obviously doesn't solve anything pre recent 10.
3. The \\?\ syntax available pre-10 is hard to use. The prefix only exists in Unicode form and suppresses any type of relative path component, changes the encoding of UNC from \\server\share to \\?\UNC\server\share, disables trailing space or period removal, and disables special casing of special devices (CON, PRN, AUX et al.) Firstly, I'm on the record as describing why most of this is generally desirable, particularly for tools that enumerate existing on disk files, but it typically means rebuilding GetFullPathName or similar so that arbitrary names can be converted into a fully qualified escaped form. I've done this before and it's under the MIT license, but it's not for the feint of heart and I could totally understand anyone wanting to avoid it.

[My1]

regarding 1: true trhat is an issue.

regarding 2: not just that it's w10 online, but the fact that it's an opti in also is an issue to some degree as the users have to enable it in the registry.

regarding 3:
I doubt these special devices are even remotely needed for a software like winfile
also while rel-paths may be an issue, it's obviously better to work with absolute paths where possible.

[craigwi]

There are a few other issues about this: #170, #99. Can we focus on one?

[SHwareSystemsDev]

For most drives, 260 chars is still more than necessary, given LFNs have their 8.3 equivalents, from the standpoint of the C and VC libraries. The glibc for Linux has a minimum of 256, which is even less, but should require filenamelen to be at least 14 (it's buggy there). This makes for a minimum maxdepth of 17 on dirs and name for drive letter based roots, as an interoperability consideration, and an effective maxpath length over 4k with a filename max of 255 that may need displaying, in MS applications. This is the state of affairs since FAT added LFN support; MS simply doesn't document it except by inference in providing interfaces like RtlGenerate8dot3Name. They leave it up to applications like WinFile to do any conversions of paths that long before use with the C APIs. If winfile isn't already using a MAXPATHLEN over 4000, imo that's nominally a bug that should be fixed, however many places it appears.

[malxau]

Two things. First, LFNs do not always have 8.3 equivalents. Specifically:

• Exfat doesn't support them
• ReFS doesn't support them
• NTFS won't have them for data volumes formatted by default
• NTFS won't have them on hard linked files
• SMB servers can do whatever they want.

8.3 names were there as a compatibility bridge in 1995. Today, they're on the way out.

Second, it's not as simple as defining a large MAXPATHLEN. The Win32 API is limited to MAX_PATH unless the caller is willing to perform all path resolution and prepend paths with \\?\. This can be done, but it's not trivial.

[SHwareSystemsDev]

Yes, most file systems don't support storing 8.3 names separately, but when FAT was the only one MS used, pre-95, it was the only thing apps had... IIRC, Netware made use of MSDOS IFS extensions, but that was the only popular software that did. The API will generate on the fly 8.3 versions for the supported code pages, SBCS or DBCS, and current file systems, even CDFS, however. I also agree it isn't simple (requires a way more robust _splitpath()/_splitURL()/_splitUNC(), for one) or I would have uploaded a patch.

[Amaroq-Clearwater]

Long Path support is a must. Additionally, being able to correctly navigate Case-Sensitive subfolders (for example, CMake versus cmake) would also be helpful for those who try to work with Linux-based filesystems.

[schinagl]

I think there are three issues here that need to be kept separate.

1. Winfile, like many legacy codebases, uses fixed sized "worst case" string lengths and does things like put them on the stack.  In order to support huge lengths, this type of thinking needs to go away and be replaced by fully dynamic allocations for all file names.  As of this writing, there are 182 instances of "MAXPATHLEN" in *.c files. 

Almost true. We will never be able to create all those strings dynamically because we do not know the weird ways those strings are passed, and when they should be freed.

So the way of choice is to update MAXPATHLEN to e.g. 1024, which is not 32767 I know, but it is an improvement

2. The Windows 10 API support is opt-in via manifest, but obviously doesn't solve anything pre recent 10.

3. The \\?\ syntax available pre-10 is hard to use.  

Can't go that way agreed

I did a quick local hack:

• removed MAX_PATH and replaced it with MAXPATHLEN, so that we have one common definition
• set MAXPATHLEN to 1024. We can afford this on the stack. If not we can increase the stack.
• Added the manifest for Windows10 > 1607 for longpathaware
• changed the registry See

And voila. the basic stuff works. Well, have to test more, I am sure a few things will pop up. ( The window caption is limited)

This was 327 characters

[schinagl]

Since #340 is on the main trunk, can we close this issue?

[craigwims]

Yep.