Re: Another weird tar issue (100 character filenames)
On Tue, Jun 27, 2006 at 01:09:40PM +0200, Jeroen van Wolffelaar wrote: On Tue, Jun 27, 2006 at 09:07:03AM +0100, Roger Leigh wrote: It sounds like a bug that dpkg is using the old v7 tar format which had that 99 char limitation.s tar has a fixed-length field for short (upto 100 bytes) filenames which is not neccessarily null-terminated. Older versions of dpkg did not care about filenames being exactly 100 bytess long and copied everything before the next null character (which happenes to be the filemode). It looks like this issue returned, the question is whether the bug in dpkg was fixed in sarge or not, since by now woody's version of dpkg doesn't really matter that much anymore. The corresponding dpkg-bug is #232025, which was fixed in dpkg 1.10.19, way before the release of sarge. Ingo -- print''x2,$/ print''x2,$/ signature.asc Description: Digital signature
Re: Another weird tar issue (100 character filenames)
On Tue, 2006-06-27 at 13:09 +0200, Jeroen van Wolffelaar wrote: But on the other hand, according to the 'be strict in what you send, liberal in what you accept' mantra, it makes sense for tar to not create tarfiles which in the past have caused issues for certain programs while there's a perfectly fine way to create tarfiles which cannot trigger such bugs. Might the patch in #230910 need to be re-crafted and re-applied? The code has changed enough that it wasn't obvious to me when moving to the new upstream that we still needed this change, but perhaps we do. If you have time to try the attached patch and let me know if it solves your problem, I'd appreciate it... I *think* this is a relatively equivalent set of changes for the current version of tar. Bdale Index: create.c === RCS file: /cvs/bdale/debian/tar/src/create.c,v retrieving revision 1.22 diff -u -u -r1.22 create.c --- create.c 22 Jun 2006 21:06:13 - 1.22 +++ create.c 28 Jun 2006 23:22:15 - @@ -633,7 +633,7 @@ return write_short_name (st); } else if (NAME_FIELD_SIZE - (archive_format == OLDGNU_FORMAT) - strlen (st-file_name)) + = strlen (st-file_name)) return write_long_name (st); else return write_short_name (st); @@ -1310,7 +1310,7 @@ block_ordinal = current_block_ordinal (); assign_string (st-link_name, link_name); if (NAME_FIELD_SIZE - (archive_format == OLDGNU_FORMAT) - strlen (link_name)) + = strlen (link_name)) write_long_link (st); st-stat.st_size = 0; @@ -1595,7 +1595,7 @@ } buffer[size] = '\0'; assign_string (st-link_name, buffer); - if (NAME_FIELD_SIZE - (archive_format == OLDGNU_FORMAT) size) + if (NAME_FIELD_SIZE - (archive_format == OLDGNU_FORMAT) = size) write_long_link (st); block_ordinal = current_block_ordinal ();
Re: Another weird tar issue (100 character filenames)
Russ Allbery [EMAIL PROTECTED] writes: I just built new xml-security-c packages to fix the current FTBFS bug, and lintian returned the following error message: E: libxml-security-c-doc: deb-created-with-broken-tar file: /usr/share/doc/libxml-security-c-doc/c/apiDocs/winutils_2XSECBinHTTPURIInputStream_8hpp-source.html N: N: The binary package was created with a broken version of tar. Some N: versions of tar contain a bug, which make the resulting .deb broken. N: On unpack, some filenames are going to be corrupted. N: N: This package was build with such a version of tar, and the mentioned N: filename is corrupted. Refer to Debian bug #230910 for more N: information, or simply update your tar-version and rebuild. (along with several other files). These filenames are indeed exactly 100 characters long, as mentioned in the referenced bug. The bug, however, indicates that this may not have really been a bug in tar but rather was a bug in dpkg with its inability to handle filenames that were exactly 100 characters (apparently one isn't supposed to nul-terminate in that case). It sounds like a bug that dpkg is using the old v7 tar format which had that 99 char limitation.s Why can't dpkg use the newer ustar or pax formats? -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpV2qb0Wfcjq.pgp Description: PGP signature
Re: Another weird tar issue (100 character filenames)
On Tuesday 27 June 2006 11:07, Roger Leigh wrote: --cut-- (along with several other files). These filenames are indeed exactly 100 characters long, as mentioned in the referenced bug. The bug, however, indicates that this may not have really been a bug in tar but rather was a bug in dpkg with its inability to handle filenames that were exactly 100 characters (apparently one isn't supposed to nul-terminate in that case). It sounds like a bug that dpkg is using the old v7 tar format which had that 99 char limitation.s Why can't dpkg use the newer ustar or pax formats? Bacause dpkg does not use libarchive yet. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another weird tar issue (100 character filenames)
On Tue, Jun 27, 2006 at 09:07:03AM +0100, Roger Leigh wrote: Russ Allbery [EMAIL PROTECTED] writes: I just built new xml-security-c packages to fix the current FTBFS bug, and lintian returned the following error message: E: libxml-security-c-doc: deb-created-with-broken-tar file: /usr/share/doc/libxml-security-c-doc/c/apiDocs/winutils_2XSECBinHTTPURIInputStream_8hpp-source.html N: N: The binary package was created with a broken version of tar. Some N: versions of tar contain a bug, which make the resulting .deb broken. N: On unpack, some filenames are going to be corrupted. N: N: This package was build with such a version of tar, and the mentioned N: filename is corrupted. Refer to Debian bug #230910 for more N: information, or simply update your tar-version and rebuild. (along with several other files). These filenames are indeed exactly 100 characters long, as mentioned in the referenced bug. The bug, however, indicates that this may not have really been a bug in tar but rather was a bug in dpkg with its inability to handle filenames that were exactly 100 characters (apparently one isn't supposed to nul-terminate in that case). It sounds like a bug that dpkg is using the old v7 tar format which had that 99 char limitation.s Actually dpkg could and can deal fine with long filenames, dpkg just had(?) a bug that a weird way of storing exactly-100-character-long filenames were not extracted properly. At some point tar created such tar archives, and dpkg went haywire on resulting .debs. It looks like this issue returned, the question is whether the bug in dpkg was fixed in sarge or not, since by now woody's version of dpkg doesn't really matter that much anymore. But on the other hand, according to the 'be strict in what you send, liberal in what you accept' mantra, it makes sense for tar to not create tarfiles which in the past have caused issues for certain programs while there's a perfectly fine way to create tarfiles which cannot trigger such bugs. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Another weird tar issue (100 character filenames)
I just built new xml-security-c packages to fix the current FTBFS bug, and lintian returned the following error message: E: libxml-security-c-doc: deb-created-with-broken-tar file: /usr/share/doc/libxml-security-c-doc/c/apiDocs/winutils_2XSECBinHTTPURIInputStream_8hpp-source.html N: N: The binary package was created with a broken version of tar. Some N: versions of tar contain a bug, which make the resulting .deb broken. N: On unpack, some filenames are going to be corrupted. N: N: This package was build with such a version of tar, and the mentioned N: filename is corrupted. Refer to Debian bug #230910 for more N: information, or simply update your tar-version and rebuild. (along with several other files). These filenames are indeed exactly 100 characters long, as mentioned in the referenced bug. The bug, however, indicates that this may not have really been a bug in tar but rather was a bug in dpkg with its inability to handle filenames that were exactly 100 characters (apparently one isn't supposed to nul-terminate in that case). I can't find any reference of this issue in dpkg's changelog, and I can't find any explicit note in the latest tar changelog or NEWS entry that indicates there was an intended change, but the patch in that bug appears to no longer be applied to the Debian tar source. Is this lintian error just obsolete and should now be removed? Or is there something more complex going on? dpkg -i installed the resulting *.deb without any difficulty and without any file name corruption that at least I can see on my Debian testing system, but I don't know if that proves this bug is gone. I don't know if this is related, but I've also started seeing the following messages from tar during package building: dpkg-deb: building package `libxml-security-c12' in `../libxml-security-c12_1.2.1-3_i386.deb'. tar: -: file name read contains nul character dpkg-deb: building package `libxml-security-c-dev' in `../libxml-security-c-dev_1.2.1-3_i386.deb'. tar: -: file name read contains nul character Is there some sort of mismatch happening between what dpkg and related tools are generating and what tar is now expecting? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
