Sometimes what a person really wants is a LACK of size

re: Sometimes what a person really wants is a LACK of size

Erzengel — Wed, 13 Dec 2006 20:36:46 GMT

I'm curious, why can't they just make the Windows API not assume the length of the (w)char buffer? Doesn't the string have to be null terminated anyway? What am I missing here that makes MAX_PATH remain?

re: Sometimes what a person really wants is a LACK of size

Michael S. Kaplan — Thu, 14 Dec 2006 01:29:53 GMT

There are many applications (both from MS and from third parties) that can and in some cases will break if the limit were arbitrarily raised, duet o the longstanding asumption. It is not simply updating a constant; it is updating a piece of the industry....

re: Sometimes what a person really wants is a LACK of size

Erzengel — Thu, 14 Dec 2006 03:29:13 GMT

Sorry I wasn't clear, I understand why giving a filename to an application, like via WIN32_FIND_DATA, would need to still be MAX_PATH (unless you go through all the fuss of making a new structure and function calls for "long" filenames--is this what FINDEX_INFO_LEVELS is supposed to be for? (I only show one possible value)).

I was talking about when you pass a string to windows. The Docs for CreateFile, for example, state that the A version can have no more than MAX_PATH, and the W version can have up to 37 thousand if it starts with "\\?\". Why does the API care?

re: Sometimes what a person really wants is a LACK of size

Michael S. Kaplan — Thu, 14 Dec 2006 05:19:24 GMT

Well, in the case of CreateFileA, there is a static buffer of the size in question -- thus a MAX_PATH limitation. This is a common pattern in many functions in the Win32 API.

re: Sometimes what a person really wants is a LACK of size

Erzengel — Thu, 14 Dec 2006 09:13:58 GMT

Then the question I have is: Why can't they make it dynamic? How would this impact applications? Isn't the static buffer on the DLL side, where it theoretically should be inaccessible by applications? Is it just because the A version is no longer "supported"?

re: Sometimes what a person really wants is a LACK of size

Michael S. Kaplan — Thu, 14 Dec 2006 10:47:18 GMT

It is because we are talking about thousands of functions and an implied chain of behavior stretching over a decade, behavior that there is a dependency on.

And external code often has the same kind of dependency created as well.

Now this is just the tip of the iceberg, but there is no way that is has ever been considered to be a simple issue -- a global change along the lines you are thinking of here would take man years of effort and would essentially break a ton of applications and code, not to mention leading to countless security holes with people overrunning buffers that are suddenly made too small in every shipping version of Windows....

re: Sometimes what a person really wants is a LACK of size

Thu, 14 Dec 2006 15:05:21 GMT

Why 260? What a strange constant... You'd think 256 or 255 or 256+3=259 ("C:\") or something like that would make more sense.

re: Sometimes what a person really wants is a LACK of size

Michael S. Kaplan — Thu, 14 Dec 2006 15:41:06 GMT

You have to leave one for the NULL maybe? :-)

No idea why they chose 260, actually....

re: Sometimes what a person really wants is a LACK of size

Mike Dimmick — Thu, 14 Dec 2006 18:50:27 GMT

I'm fairly sure there's a part of MSDN Library which mentions that it's 3 for the drive specification (e.g. "C:\"), 256 for the path, and 1 for the terminating NULL = 260 total.

A slight difference with the \\?\ syntax is that these can only be absolute paths, not relative ones. Regular paths (not starting with \\?\) are relative on desktop Windows; coming from Windows CE I'm used to a lack of support for relative paths (all paths are absolute on CE, so if you say CreateFile( L"Blah.txt" ) your file ends up in the root - there is no SetCurrentDirectory API).

Really \\?\ is just an escape to the Win32 API to tell it to pass the path unchanged to the underlying NT native API (e.g. NtCreateFile), rather than prepend the supplied path with the current directory (the native API only works with absolute paths, the current directory is a Win32 concept).

Clearly the absolute path to a file can already exceed MAX_PATH characters, because of these two features (you can pass a MAX_PATH relative filename to CreateFile when the current directory is not a root path). The question is how to work around the problem. It was done in the move from Win16 to Win32, but of course people had to recompile their programs for that, and the backcompat scheme of generating the 8.3 name was retained.

re: Sometimes what a person really wants is a LACK of size

Rosyna — Fri, 15 Dec 2006 04:16:56 GMT

i've probably said this so many times that it's becoming old. Paths are evil and should be banished by law. If there were no paths, imagine how much simpler everything would be.

re: Sometimes what a person really wants is a LACK of size

Michael S. Kaplan — Fri, 15 Dec 2006 04:41:29 GMT

Hmmm.... a little late for that? :-)

re: Sometimes what a person really wants is a LACK of size

Jon — Tue, 02 Jan 2007 05:07:14 GMT

I say break all those apps (how do we know it'll break a lot of apps, isn't that an assumption in itself?). Seriously. I'm so tired of this limitation, it's breaking stuff RIGHT NOW. It's really inexcusable. Plenty of other OSes do not have problems with this. Make a break for it!

Or at the very least introduce an undocumented option for experts!

Will we be sitting here in 5 years' time still agonizing about the 260 char path limit? 10 years? 20 years?

Gah.

re: Sometimes what a person really wants is a LACK of size

Michael S. Kaplan — Tue, 02 Jan 2007 05:22:56 GMT

Microsoft has AppCompat labs containing many thousands of apps written by Microsoft and other companies, so we do not ever have to guess that things might break in situation -- we know when they might do so.

If a new version "fixed" the limitation and those apps would fail or introduce security holes by overrunning buffers, it is pretty certain that Microsoft would be blamed for boith the breaks and the security holes.

Working and safe is a more palatable option for all concerned....

Windows Vista junctions points, MUI and localized folder names

Carlos Quintero's blog — Mon, 12 Feb 2007 13:33:28 GMT

I spent quite a few hours yesterday dealing with an intriguing thing that hapenned two days ago while

Long Paths in .NET, Part 1 of 3 [Kim Hamilton]

BCL Team Blog — Tue, 13 Feb 2007 19:12:28 GMT

Let’s start by looking at one of the more interesting exception messages in the BCL, the PathTooLongException:

An opportunity to start down the right [long ]path

Sorting It All Out — Wed, 14 Feb 2007 00:59:16 GMT

I have posted previously in entries like Sometimes what a person really wants is a LACK of size about

Long Paths in .NET, Part 1 of 3 [Kim Hamilton][译]

Tom's Notepad — Thu, 26 Apr 2007 08:54:46 GMT

让我们从BCL中的一个有趣的异常开始今天的话题:

Ask a simple question, and then duck!

Sorting it all Out — Fri, 30 May 2008 05:54:15 GMT

The whole thread started innocently enough, with a simple question: Check out this shell command I typed