1

Sorry I haven't tested this myself, but MSDN says we can make a very long (more than MAX_PATH ie. 260 chars) file name by specifying "Win32 file namespace":

That's easy with the CreateFile API because its signature accepts LPCTSTR lpFileName which incurs no restriction about the input length:

But how can we read such a long file name? W32_FIND_DATA returned by FindFirstFile contains only TCHAR cFileName[MAX_PATH].

Will we perhaps get 8.3 name instead when the actual file name doesn't fit into cFileName[MAX_PATH]?

nodakai
  • 7,773
  • 3
  • 30
  • 60
  • 1
    Can a single file name be greater than `MAX_PATH`? Because you can easily have a file system with a path greater than `MAX_PATH` but no one file or folder is longer than `MAX_PATH`. – ta.speot.is Nov 26 '14 at 11:43
  • It appears it cannot, at least on NTFS: http://stackoverflow.com/a/265782/242520 *Individual components of a filename (i.e. each subdirectory along the path, and the final filename) are limited to 255 characters, and the total path length is limited to approximately 32,000 characters.* – ta.speot.is Nov 26 '14 at 11:44
  • So, apparently I confused the length limit on a *path* with the limit on its *component* (for a path `\boo\foo\woo`, its components are `boo`, `foo`, and `woo`.) But still... The quoted answer cites "Naming Files, Paths, and Namespaces" page which I didn't find very clear about the length limit on a path *component*. – nodakai Nov 26 '14 at 12:00

1 Answers1

2

For CreateFile, you can escape the MAX_PATH limit by using the Unicode version of the API, and the special L"\\?\" prefix.

For W32_FIND_DATA things are a little different. That record contains the file names as inline character arrays. With fixed length. However, these filenames in the record only contain the name of the object relative to its container. By that I mean these filenames are relative to the directory in which they live. And so the limitation that they can be no more than MAX_PATH in length is in fact not a limitation, because each component in a path is itself limited in length, typically to be no more than 255 characters.

The limitation of path components to 255 characters in length is discussed in the very MSDN article to which you linked: Naming Files, Paths, and Namespaces.

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

splash
  • 13,037
  • 1
  • 44
  • 67
David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Yeah, I read `lpMaximumComponentLength` was commonly `255`. But "commonly" doesn't help much in understanding specifications.... So, the fact is, it is effectively limited by `260` by the design of Win32 API. Am I correct? – nodakai Nov 26 '14 at 12:19
  • I can't see how anyone could implement a file system that supported components with longer names because you could not enumerate directory contents. So yes, the design of the API in effect imposes that particular limit. As for commonly, I believe that the common limits are 12 for 8.3 drives and 255. – David Heffernan Nov 26 '14 at 12:23