5

I was wondering, what is the longest possible name length allowed by the Windows kernel?

E.g.: I know the kernel uses UNICODE_STRING structures to hold all object paths, and since the byte length of a wide-character string is stored inside a USHORT, that allows for a maximum path length of 2^15 - 1 characters. Is there a similar, hard restriction on a file name (rather than path)? (I don't care if NTFS or FAT32 imposes a particular restriction; I'm looking for the longest possible theoretically allowed name in the kernel, assuming no additional file system or shell restrictions.)

(Edit: For those wondering why this even matters, consider that normally, traversing a directory is achieved by FindFirstFile/FindNextFile calls, one call per file. Given the function named NtQueryDirectoryFile, which is the underlying system call and which returns multiple file names per call, it's actually possible to take advantage of this maximum-length restriction on the path to make an extremely-fast directory traverser that uses solely the stack as a buffer. Now I'm trying to extend that concept, and I need to know the maximum size of a file name.)

user541686
  • 205,094
  • 128
  • 528
  • 886
  • When you say USHORT and then 2^31, what do you mean? If it is unsigned then it would be 2^32, but a ushort only stores up to 2^16 (It's 16bits long) Have I misunderstood your meaning somewhere? – James Jan 07 '11 at 09:26
  • Sorry, that was a typo; I meant 2^15 - 1. I changed it, thanks. – user541686 Jan 07 '11 at 09:27
  • And I forgot to take into account that each character needs 2 bytes of memory, halving the amount space you get... Anyway, I'm guessing that such a limit in the kernel would be poorly documented and vary from XP to Vista/Win7. Hope someone can help you, +1 – James Jan 07 '11 at 09:31
  • Is your method measurably faster enough to make any meaningful difference? If there is some internal limit, what would stop Microsoft from changing it in the future? As far as I know path components are limited only by the underlying file-system; I doubt it's ever going to go above 255 in the foreseeable future (mainly for backward compatibility purposes). – Luke Jan 07 '11 at 19:00
  • Yes, it iterates through my entire C: drive (which has Windows 7, with a total of about 400,000 files) in less than four seconds, if the entire data to be read is cached in system memory. As soon as I switch to using malloc() instead of stack-based memory, the time taken at least doubles -- sometimes more. And I've noticed that it's probably one or two orders of magnitude faster than Explorer when it searches for files. If you're interested, I can post the code somewhere, although it's written in D. – user541686 Jan 07 '11 at 19:05

2 Answers2

5

The maximum length of a path is 32,767 characters whereby each path component (directory or file) can have a maximum length of 255 characters (to be more exact, the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function).

This is documented on MSDN.

Helge Klein
  • 8,829
  • 8
  • 51
  • 71
  • +1, Thank you for the link, it's useful. But I'm looking for a compile-time, absolute maximum, and the page says 255 is "commonly" the maximum. So my question is, there any absolute upper barrier aside from 32K? – user541686 Jan 07 '11 at 10:09
  • (Oops sorry, forgot to give the +1; fixed.) :) – user541686 Jan 07 '11 at 16:45
  • I think I'll just accept this since I don't think there's a better answer. Thanks. :) – user541686 Jan 21 '11 at 20:29
2

Ah, I found this page myself that guarantees that file names can't be longer than 255 characters:

  • A pathname MUST be no more than 32,760 characters in length.
    ...
  • Each pathname component MUST be no more than 255 characters in length.

Which makes me wonder:

Why does Windows use ULONGs for file name lengths, when it uses USHORTs for path lengths?!

If anyone knows why this is, please post/comment! I'm rather curious. :)

Community
  • 1
  • 1
user541686
  • 205,094
  • 128
  • 528
  • 886
  • 2
    The ULONGs are probably used to maintain alignment with the other fields in the directory information header records. The USHORT limit of UNICODE_STRING is the real limit. Using a USHORT in the info header would either require a padding value or put the rest of the structure out of alignment. Note that each header record needs to be aligned by 8 byes. – Chris Smith Oct 18 '11 at 15:24