[flac-dev] Very long filenames in Windows

lvqcl lvqcl.mail at gmail.com
Sat Sep 20 02:51:24 PDT 2014


> By the way... according to MSDN page for CreateProcess() function
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx>:
> "The maximum length of [the command line] is 32,768 characters, including the Unicode terminating null character".
>
> UTF-8 uses up to 4 bytes for a character, so the maximum length of
> a temporary buffer for a call like
>
> 	flac_fprintf(stderr, "%s: ERROR: couldn't get block from chain\n", filename);
>
> should in theory exceed 4*32768 = 131072 bytes (plus some space for
> the rest of the message).
>
> Currently *printf_utf8() functions allocate 32768 bytes buffer.


More info (see also <http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx>):

A file path is limited by 260 characters. But WINAPI also supports
an extended-length path (it has "\\?\" prefix) which is limited by
32767 unicode characters:

	\\?\c:\path\to\filename.ext

FLAC uses __wgetmainargs to obtain Unicode command line arguments.
This function can also expand wildcards. But in this case it converts
"\\?\c:\path\to\filename.ext" into just "\\filename.ext" (looks like
a bug in MS code). So currently FLAC doesn't support very long paths.
Disabling of wildcards expansion fixes this, and FLAC will be able to
en- and decode files with an extended-length path.

(what do you prefer: wildcards expansion OR extended-length path support?)

...On the other hand, _wstat64 function in MSVC runtime doesn't like '?'
inside paths, and as a result grabbag__file_get_filesize() returns -1.
So disabling of wildcards expansion will not result in 100% support of
long file paths in FLAC.


More information about the flac-dev mailing list