Re: Filename limits

[Chuck McDevitt <cmcdevitt at ABINITIO dot COM>]

Shankar Unni wrote:

>
> The Unicode versions of several functions permit a maximum path length 
> of 32,767 characters, composed of components up to 255 characters in 
> length. To specify such a path, use the "\\?\" prefix. For example, 
> "\\?\D:\<path>". To specify such a UNC path, use the "\\?\UNC\" 
> prefix. For example, "\\?\UNC\<server>\<share>". Note that 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. An 
> implication of this is that you cannot use forward slashes to 
> represent path separators or a period to represent the current 
directory.


If I have understood the documentation correctly, using the Unicode 
version of file functions (e.g. CreateFileW) and prepending \\?\ allows 
32k character path limit.

It would be possible to change all instances of CreateFile, MoveFile, 
DeleteFile, etc. to CreateFileW, MoveFileW, etc. and create a function 
that converted the win32 path into a unicode version (possibly something 
like path_conv.get_nt_native_path()).

The one drawback I can see is with compatibility:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createfile.asp 

wrote:

> *Windows Me/98/95:  **CreateFileW* is supported by the Microsoft Layer 
> for Unicode. To use this, you must add certain files to your 
> application, as outlined in Microsoft Layer for Unicode on 
> Windows 95/98/Me Systems 
> <
http://msdn.microsoft.com/library/en-us/mslu/winprog/microsoft_layer_for_unicode_on_windows_95_98_me_systems.asp
>.

The best solution would to select either CreateFileA or CreateFileW at 
runtime, depending upon the system it is being run on.  However, what 
would happen if CreateFileW was linked (but not called) on a non-Unicode 
enabled win 95/98/Me system?

I noticed in fhandler.cc there is a reference to NtCreateFile, which 
according to msdn, is XP and 2000 only.  What happens on a win95 machine?

This would be a /real benefit/ if cygwin supported longer path names.

-- Colin


------------------------------------------------------------------

Yes, paths with \\?\ prepended can be up to 32k in length, but they are 
NOT parsed via the normal win32 rules, so special names like device names 
(NUL, CON, LPT1, etc) are not recognized, relative paths don't work, etc. 
You'd have to make special checks.

And I think these long path names only work on NT based Windows systems 
(nt, 2000, xp, etc).

NtCreateFile & NtOpenFile are the "native" windows NT routines for opening 
files.  They only support UNICODE, 
and support paths up to 32k.

CreateFileW is just a wrapper around NtCreateFile on nt-based systems.  If 
the path is prepended with "\\?\", it gets passed unparsed and unmodified 
to NtCreateFile (and so supports 32k length).

CreateFileA on an nt-based system just converts all strings from MBCS to 
Unicode via the current locale's code page, and then calls CreateFileW. 
CreateFileA is always limited to MAX_PATH.

On Win98/WinME, it works differently.   There is no routine called 
NtCreateFile.

CreateFileW is a dummy routine that always returns an error, unless you 
link with the Microsoft Layer for Unicode (Unicows.dll).  Unicows.dll 
translates all UNICODE argument strings to the current code page, and 
calls CreateFileA.

So you can always link with CreateFileW, since it always exists, but it 
may not be functional.


The special \\?\ prefix doesn't do what you want on Win9x systems, as you 
always go through CreateFileA, so paths are always limited to MAX_PATH.










ForwardSourceID:NT00034B0A 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/