|
From: | Henrik Grubbström |
Subject: | Re: [Bug-tar] Re: USTAR interoperability with Solaris 10 /bin/tar |
Date: | Sat, 30 Sep 2006 18:48:20 +0200 (CEST) |
On Sat, 30 Sep 2006, Joerg Schilling wrote:
Henrik Grubbström <address@hidden> wrote:On Thu, 28 Sep 2006, Henrik Grubbström wrote:Hi. I need to create tar archives with deep paths on a Linux machine that Solaris 10's system tar (ie /bin/tar) can extract. If I read the manuals correctly, this should be achievable by using the USTAR format.[...]So the main difference seems to be that the file name is missing in the record for the first long path in the gnutar case. Any suggestions for a patch?Suggested patch against 1.15.91 attached.Could you tell more about the constraints? While GNU tar by default still ctreates non-standard archives that cause problems with tar archivers that don't understand the vendor unique format used by GNU tar, my tests show since a year that GNU tar may handle long path names correctly if you do the right things: Either use DEFAULT_ARCHIVE_FORMAT=USTAR when calling configure or call gtar -Hustar What path names did you use to cause the problems?
See my original message for an example.The problem was that when gnu tar attempted to archive a directory with a path longer than NAME_FIELD_SIZE (ie 100 characters), but shorter than PREFIX_FIELD_SIZE (ie 155 characters), that ended with a directory separator, it would put the entire path in the prefix block, and leave the name field empty. Some tar's (eg Solaris') interpret a block with an empty name field as the EOT marker.
My patch makes it try to fit as much as possible of the path into the name field, and just the remainder in the prefix.
Jörg -- EMail:address@hidden (home) Jörg Schilling D-13353 Berlin address@hidden (uni) address@hidden (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-- Henrik Grubbström address@hidden Roxen Internet Software AB
[Prev in Thread] | Current Thread | [Next in Thread] |