■ Long file name armageddon pending with windows 10 anniversary

Many people wonder why in this day and age windows filesystem has the silly MAX_PATH restriction, where a total filename including its folder path (location) cannot exceed 260 characters. It restricts the use of verbose explanatory folder names. However it is here with us, and programmers from at least windows 95 (20 years worth of code) have been used to sizing path buffers for [MAX_PATH] — xplorer² included. The 260 letter restriction has lived so long because:

It was an improvement over the older (even worse) MSDOS 8.3 file naming convention
Very few people felt its grip, or at least learnt to live with it naming their folders (especially top level ones) with moderation
The Shell including windows explorer and the open/save dialog boxes didn't like really long filenames

The last point is especially important for the longevity of MAX_PATH. Although supposedly the low level file operation API supported paths of up to 32767 characters for some time, using a special prefix to path names (\\?\D:\VERY\LONG\PATH), nobody in their right mind used this system because very few programs could read such deep paths. What's the point of going extravagant with descriptive names if that caused your editor program to fail loading the document? This basic consideration persuaded me to postpone long filename support in xplorer².

Then last summer I read rumors that windows 10 would enable really long filenames by default in windows explorer, and sure enough after the windows 10 anniversary update (version 1607) everyone talks about the abolition of the 260 letter rule, ~~windows shell included~~ apparently. All you need to do is set the system registry key value LongPathsEnabled to 1 (in HKLM\SYSTEM\CurrentControlSet\Control\FileSystem) and Bob's your uncle. I am not sure how many non-microsoft programs (if we assume that their MS programs can live with it, TBC) can live with such a ground-breaking file naming change.

It gets worse for compatibility. Apparently windows 10 is turning 8.3 names (that used to exist in parallel with the "real" long names) off by default for any non-system partition you create (they still appear for C:\ for the time being). Quoting performance gains for dropping 8.3 names sounds reasonable, but the professed improvements only show in extremely large folders (who has one million files in any single folder?). And what about legacy programs? Combine huge file names without a short 8.3 alternative and you have guaranteed that 99% of the programs out there are stranded. There isn't even provision for an API to check if 8.3 names are disabled; you'd have to check registry keys like NtfsDisable8dot3NameCreation and for the usual setting you'd need admin privileges just to query the status on a volume using fsutil 8dot3name. Madness; they shouldn't have kicked poor Balmer out, the guy was a saint in retrospect <g>

I am certain that this drastic change will bite many MS shell departments as well. Old school drag drop with WM_DROPFILES and shell execution (cue %1 argument for open verbs), shell API like SHGetPathFromIDList, even shell data structures like SHCOLUMNDATA all come with MAX_PATH "disease". The constant is present in many MFC and ATL/WTL headers too — don't just look at your own source code. It will be a big knot to untangle.

Obviously now the die is cast, and I will have to sort out xplorer² with the new really long paths in a forthcoming version. But it is an unenviable task. A quick search for MAX_PATH in the source code finds it used in 326 places in various parts of the program. It is going to be a major and deep revision, frankly with little benefit for the average user. But that's developers' life, nasty, brutish and short

ADDENDUM. On closer inspection the LongPathsEnabled tweak doesn't do much. Windows explorer (including system open/save dialog boxes), and all the shell framework (anything that uses IShellFolder or IShellItem) still cannot handle super-long paths. So all this hype is pointless because the low level API was already able to handle long paths, albeit with the \\?\ prefix. If the windows shell ever beats the MAX_PATH limitation, then we'll talk again <g>

The old DOS command processor CMD.EXE doesn't want to know about huge paths either, but powershell is good for any depth!

ps. xplorer² version 3.4 is long path enabled!