Nope. Looks good, please submit with a Changelog. Thanks
Rob > -----Original Message----- > From: Ralf Habacker [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 27, 2002 5:08 AM > To: Cygwin-Apps; Binutils > Subject: RE: Problem with cygwin install. > > > > > Nope. You'll need to debug it. I tested this after > Nicholas's recent > > > remondier and it worked for me. > > > > > I have tried and recognized, that there are problems with > the GNU long > > name extension in archive_tar.cc. The filenames which fails > are always > > over 100 characters long and this is the limit. Does anyone > have some > > informations about how this extension works ? > > It seems noone, so it needs a little more time to analyse > this bug, but I think I've catched this bug: > > The problem was, that in archive_tar::next_file_name() in > case of filenames with the GNU long name extension a flag > "state.have_longname" is set, but never reset, which inhibits > propper generating of following filenames in the archive. > > 2002-05-26 Ralf Habacker <[EMAIL PROTECTED]> > > * archive_tar.cc (archive_tar::next_file_name()) fixed broken > GNU long name extension support. > > Index: archive_tar.cc > =================================================================== > RCS file: /cvs/cygwin-apps/setup/archive_tar.cc,v > retrieving revision 2.8 > diff -u -3 -p -B -b -B -p -r2.8 archive_tar.cc > --- archive_tar.cc 5 May 2002 04:02:00 -0000 2.8 > +++ archive_tar.cc 26 May 2002 19:00:37 -0000 > @@ -168,6 +168,8 @@ archive_tar::next_file_name () > memcpy (state.filename, state.tar_header.name, 100); > state.filename[100] = 0; > } > + else if (state.have_longname) > + state.have_longname = 0; > > sscanf (state.tar_header.size, "%o", &state.file_length); > state.file_offset = 0; > > Any comments before submitting ? > > > Ralf > >