Re: Today's long path name patch

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Mar  8 11:36, Corinna Vinschen wrote:
> On Mar  8 10:49, Corinna Vinschen wrote:
> > Hi Brian,
> > 
> > thanks for testing!
> > 
> > On Mar  7 17:02, Brian Dessent wrote:
> > > Corinna Vinschen wrote:
> > > 
> > > > as I threatened the community with today, I've now checked in my patch
> > > > which finally enables long path names in Cygwin.  I tested it on XP,
> > > > 2008, and 2008 x64.  What this patch does:
> > > 
> > > Hmm.  I was playing with this code using the attached testcase.  It
> > > simply tries to open(O_RDWR | O_CREAT | O_TRUNC) a filename that
> > > contains 256 chars, nothing else.  The call to open fails with errno =
> > > ENOENT.  The strace from fhandler_base::open and on looks like this:
> > > [...]
> > >    25   41152 [main] tc 3304 fhandler_base::open: C0000033 =
> > > NtCreateFile (0x0, C0100000,
> > > \??\C:\cygwin\home\brian\testcases\long-file-name-create\256charfilename[+241
> > > underscores], io, NULL, 81, 7, 5, 4420, NULL, 0)
> > > [...]
> > > So NtCreateFile is returning STATUS_OBJECT_NAME_INVALID.  Did I
> > > misunderstand what's supported, is there a limitation on each
> > > path-component or just the total length of the absolute path?  I checked
> > > the attr.ObjectName and it appears to be correctly set.
> > 
> > Every path component is restricted to the length defined by NAME_MAX,
> > which is 255 bytes.  This is not different from other systems and defined 
> > in limits.h as per POSIX.
> 
> Huh!  You uncovered a bug in symlink_info::check.  I ran your testcase
> and it tries to open the file with a .lnk attached.
> 
> symlink_info::check first tries to get info for the plain filename.
> This fails with STATUS_OBJECT_NAME_NOT_FOUND, so it tries to get
> info for the same filename with .lnk attached.  However, now the
> filename is longer than allowed for a path component and
> NtQueryAttributesFile returns with STATUS_OBJECT_NAME_INVALID, which
> is handled differently than STATUS_OBJECT_NAME_NOT_FOUND.
> 
> I'll look into fixing that.

Should be fixed, together with a dumb bug in readdir.  Since I defined
the target buffer size in a call to sys_wcstombs as NAME_MAX instead of
NAME_MAX+1, the last character of a 255 bytes long filename was always
overwritten with a trailing \0.  Uh oh.


Corinna

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