Friday, April 7, 2006

The .NET Framework can't count past 256

Anyone who did arts in university can stop reading now.

For the most part, I really like developing .NET applications. I think Microsoft has done a fairly good job at making a framework that's pretty nice to use. But there are some things that just piss me the fuck off.

A case in point: I'm not sure how many people know this, but there is a maximum length for a file's path; actually, there's two maximum lengths. The FAT filesystems (FAT16, FAT32) had a limit of 256 characters. Remember the days of 8.3 filenames? You'd have to nest a file fairly deep in a folder hierarchy to get to 256 characters. With the advent of Windows NT, and subsequently windows 2000 and XP, they came up with NTFS, the NT filesystem. Since this filesystem natively supported long filenames, not the silly ~1 kludge that 95, 98, and ME bore, 256 suddenly became not such a hard length to hit. They upped the maximum path length to 32768 characters. That ought to be enough for everyone, right? I still don't know who in their right mind would want to type 32k of characters to get to a file :)

My problem is that the .NET framework, now in its 2.0 incarnation, and I'm pretty sure working only on operating systems that use NTFS, cannot access a file with a path longer than 256 characters. There has been a way to access these long paths since around 1997 in Windows NT 3.51, yet here in 2006 we can't seem to get past 256 characters. This made me want to kick a framework developer square in the juniper berries.


Anonymous said...

Seems to have started as (or may still be) a Windows thing.

XP has a similar problem with the "PATH" variable, but that's 1023 (+terminator).

I have encountered similar pathing problems with other tools; such as source control views in Rational ClearCase. *shrug*

Anonymous said...

The fact remains that you can access long paths with the Win32 API but you can't with the .NET Framework. That's my main reason for outrage. Check out this MSDN article:

Maximum Path Length

In the Windows API, the maximum length for a path is MAX_PATH, which is defined as 260 characters. A path is structured in the following order: drive letter, colon, backslash, components separated by backslashes, and a null-terminating character, for example, the maximum path on the D drive is D:\[256 chars]NULL.

The Unicode versions of several functions permit a maximum path length of approximately 32,000 characters composed of components up to 255 characters in length. To specify that kind of path, use the "\\?\" prefix.


The maximum path of 32,000 characters is approximate, because the "\\?\" prefix can be expanded to a longer string, and the expansion applies to the total length.

For example, "\\?\D:\<path>". To specify such a UNC path, use the "\\?\UNC\" prefix. For example, "\\?\UNC\<server>\<share>". These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory. Also, you cannot use the "\\?\" prefix with a relative path. Relative paths are limited to MAX_PATH characters.

When using the API to create a directory, the specified path cannot be so long that you cannot not append an 8.3 file name.

The shell and the file system may have different requirements. It is possible to create a path with the API that the shell UI cannot handle.

Anonymous said...

Will they not change this with Longhorn?
I'm sick of this MAX_PATH=260 crud.
In 2007, when the file system supports 32k, why am I still battling with 260???
My worst problem with Windows at the moment!!!
Come on Microsoft. deal with this!