Fw: File name too long problem -- maybe fix coming?

Corinna Vinschen corinna-cygwin@cygwin.com
Mon Jan 14 10:53:00 GMT 2008

On Jan 10 12:04, Corinna Vinschen wrote:
> On Jan  9 06:53, Eric Blake wrote:
> > According to Corinna Vinschen on 1/9/2008 5:44 AM:
> >> Actually, for a couple of weeks I'm already wondering if we shouldn't
> >> better set PATH_MAX to 32000 or even a smaller value like 16384.  That's
> >> still a darn long path and it's much more safe to handle.
> >
> > If we follow Linux' lead, then set PATH_MAX to the largest sequence we are 
> > willing to handle at once (even 4096 would be fine by me) in the arguments 
> > given to most syscalls, provided that we also support the ability to access 
> > files with longer names by using relative paths that fit within PATH_MAX 
> > (for example, with the addition of *at functions).
> Apart from that, you are suggesting to differ consequently between the
> externaly handled POSIX path length as defined by PATH_MAX, and the
> internal max path length which would be something along the lines of
> 32K for obvious reasons, right?
> That sounds like an interesting idea.  Maybe we should really just
> restrict PATH_MAX to 4K as on Linux.  "Nobody will ever need more than
> 4K bytes long pathnames"(C).
> >   Then only a few special 
> > functions will have to support strings longer than PATH_MAX (for example, 
> > the Austin Group is adding requirements to getcwd in the next revision of 
> > POSIX that makes it always accurate, even if the current directory has an 
> > absolute path longer than PATH_MAX, because it was reached in stages 
> > through relative directories).
> Ok, returning arbitrary strings in buffers provided by the application
> shouldn't be a problem anyway.

Btw., what about functions returning Win32 paths?

When they return paths longer than MAX_PATH characters, they are
unusable as input to Windows tools.  Even if the path has \\?\
prepended, it's still in ANSI/OEM/UTF-8.  But the A type functions are
not capable of this syntax, nor long path names.  So the output of
cygpath is only usable for short path names.

In theory, we would need new functions along the lines of

  int cygwin_conv_to_*wide*_win32_path (const char *posix, wchar_t win32);

which return paths so that they can be used in the W type of win32
functions.  That's of course not helpful for cygpath and scripting, but
these restrictions in the API and the Win32 command line tools is not
exactly our fault, is it?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list