<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>217552</bug_id>
          
          <creation_ts>2008-04-13 20:04 0000</creation_ts>
          <short_desc>app-arch/rzip fails on files bigger than 4GB</short_desc>
          <delta_ts>2009-11-27 12:34:40 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Applications</component>
          <version>unspecified</version>
          <rep_platform>All</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>NEW</bug_status>
          
          
          
          
          <priority>P2</priority>
          <bug_severity>major</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <votes>10</votes>
          <everconfirmed>1</everconfirmed>
          <reporter>info@petamem.com</reporter>
          <assigned_to>maintainer-needed@gentoo.org</assigned_to>
          <cc>bangert@gentoo.org</cc>
    
    <cc>emmi3@gmx.de</cc>
    
    <cc>info@petamem.com</cc>
    
    <cc>sbriesen@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>info@petamem.com</who>
            <bug_when>2008-04-13 20:04:21 0000</bug_when>
            <thetext>rzip silently fails to compress files bigger than 4GB. There seems to be a 32bit overflow (even on 64bit architectures - also seen on AMD64). As soon as the file is bigger than 4GB, the compressed file size is somewhere filesize MODULO 4GB. Tested with a 6GB DVD image and a 9GB DVD Image. The rzip-author didn&apos;t react to this bug report. What&apos;s worse, the ebuild description states &quot;compression program for large (sic!) files&quot; -&gt; *boom*

Reproducible: Always

Steps to Reproduce:
1. Get ISO-Image bigger than 4GB; get its MD5 sum
2. compress iso image with rzip -6 
3. decompress compressed file, get its MD5 sum

Actual Results:  
The compressed file is broken

Expected Results:  
Being able to recover compressed data lossless

Either fix, or document</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>darkside@gentoo.org</who>
            <bug_when>2008-05-22 04:08:18 0000</bug_when>
            <thetext>Thanks for reporting, quite a valuable find for someone I&apos;m sure. I will add a notice to the ebuild. Can you provide documentation to the upstream bug report that you filed please.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>darkside@gentoo.org</who>
            <bug_when>2008-05-23 23:13:08 0000</bug_when>
            <thetext>(In reply to comment #0)
&gt; Either fix, or document

pkg_postinst() {
    ewarn &quot;It has been reported that this tool will fail on files &gt;4GB&quot;
    ewarn &quot;Please see https://bugs.gentoo.org/show_bug.cgi?id=217552 for more&quot;
    ewarn &quot;information.&quot;

Added to ebuild. Thanks for reporting. Closing bug but please still comment with the $UPSTREM bug report that you filed so later users can investigate.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>mlq.gentoo@codedaemon.com</who>
            <bug_when>2008-05-25 12:22:07 0000</bug_when>
            <thetext>I ran into this a long time ago.  What happened in my case is that the generated rz did contain all of the data, it&apos;s just that the header stored the expected file size as an int instead of a long or long long.  All I had to do in my case was modify the source so that it ignored the stored file size and instead read until it hit EOF...  I think that&apos;s what I did, this was a while ago.

p7zip FTW! :-)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>sbriesen@gentoo.org</who>
            <bug_when>2008-07-08 13:53:03 0000</bug_when>
            <thetext>@Comment 3: so the rz-files are basically ok, but can not be extracted correctly. Would you be so kind and provide us your little patch? ;)

would be nice, so one can at least extract that &quot;broken&quot; files. Thanks!
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>idontwantspam@mailinator.com</who>
            <bug_when>2008-07-27 18:01:15 0000</bug_when>
            <thetext>The bug is introduced by patching rzip with rzip-2.0-darwin.patch. The patch screws up rzips large file handling. </thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>idontwantspam@mailinator.com</who>
            <bug_when>2008-07-27 20:19:04 0000</bug_when>
            <thetext>Created an attachment (id=161489)
Fixed the patch so that it doesn&apos;t screw up large file support.

I haven&apos;t checked all the changes that the original rzip-2.0-darwin.patch does, but I removed the part that messed with the large file support. Please update the patch in portage with this version and remove the warning from the ebuild.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>idontwantspam@mailinator.com</who>
            <bug_when>2008-07-30 18:36:24 0000</bug_when>
            <thetext>Created an attachment (id=161756)
Patch for rzip to enable uncompressing of archives created with the broken rzip.

Please reopen this bug - this issue is definitely not fixed. If someone used gentoo&apos;s broken rzip to compress a large file, {,s}he may look for open bug reports.

The attached patch implements an option &apos;-l&apos; that can be used to override the higher 32bits of the expected file size and thereby allowing the uncompressing  of broken rzip-files. It should be okay to use a higher value than the correct one.

Example:
rzip -d -l 200 broken_archive.rz</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>darkside@gentoo.org</who>
            <bug_when>2008-07-30 18:49:22 0000</bug_when>
            <thetext>(In reply to comment #7)

&gt; Please reopen this bug - this issue is definitely not fixed. If someone used
&gt; gentoo&apos;s broken rzip to compress a large file, {,s}he may look for open bug
&gt; reports.

AKAIK, anyone can reopen bugs. can&apos;t remember though. Thanks for the patch, I&apos;m hesitant to remove the darwin patch, because I don&apos;t have time at the moment to see what that does and what it will possible break.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>darkside@gentoo.org</who>
            <bug_when>2008-07-30 18:51:39 0000</bug_when>
            <thetext>Un-assigning from myself because for above mentioned reasons. (I also would like to test this and don&apos;t have any large files available at the moment)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>idontwantspam@mailinator.com</who>
            <bug_when>2008-08-01 15:54:42 0000</bug_when>
            <thetext>I only had the option to &quot;Leave as RESOLVED FIXED&quot; on the closed bug report. If there is another way to re-open reports, please tell me.

But why are you hesitant to remove the patch for it might break something (well, actually I didn&apos;t even ask for that but to replace it)?! It _already_ breaks rzip silently.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>emmi3@gmx.de</who>
            <bug_when>2008-08-29 16:29:00 0000</bug_when>
            <thetext>I can confirm that the original patch definitely breaks rzip, whereas the updated patch works just fine. I honestly don&apos;t see any reason why a *known broken* version of rzip should stay in the portage tree (even marked as stable!) while a version that is known not to contain this bug (but *maybe* some others) is not even added to the tree.
I was just lucky to see the log-messages this time.

From my point of view the current rzip-version in portage should at least be marked as unstable, or even better: masked completely and a version with this reworked patch should be added to the tree.

@Stupid Bugzilla: thank you for the both of your patches! So I could at least recover everything from the broken archives.

@Jeremy Olexa: for big files how about sth. like
dd if=/dev/zero of=/some/place/with/space/testfile bs=1024k count=5024
to get a 5GiB file?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>bangert@gentoo.org</who>
            <bug_when>2009-11-27 12:34:40 0000</bug_when>
            <thetext>what&apos;s the status here? is the problem solved, for current in-tree versions of rzip?</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>161489</attachid>
            <date>2008-07-27 20:19 0000</date>
            <desc>Fixed the patch so that it doesn&apos;t screw up large file support.</desc>
            <filename>rzip-2.1-darwin.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">ZGlmZiAtciAtdU4gcnppcC0yLjEvY29uZmlndXJlLmluIHJ6aXAtMi4xLXBhdGNoZWQvY29uZmln
dXJlLmluCi0tLSByemlwLTIuMS9jb25maWd1cmUuaW4JMjAwMy0xMS0wMyAwOToxOToxMS4wMDAw
MDAwMDAgKzAxMDAKKysrIHJ6aXAtMi4xLXBhdGNoZWQvY29uZmlndXJlLmluCTIwMDgtMDctMjcg
MjE6NTk6NDUuNzc0NzQwMzAzICswMjAwCkBAIC0yLDYgKzIsMTIgQEAKIEFDX0lOSVQobWFpbi5j
KQogQUNfQ09ORklHX0hFQURFUihjb25maWcuaCkKIAorIyB0ZXN0IHByaW9yIHRvIEFDX1BST0df
Q0MsIHNpbmNlIGl0IHNldHMgY2ZsYWdzIG9uIGl0J3Mgb3duLgoraWYgdGVzdCB4IkNGTEFHUyIg
PSB4Cit0aGVuCisJREVGQVVMVF9DRkxBR1M9Ii1nIC1XYWxsIC1PMyIKK2ZpCisKIGRubCBDaGVj
a3MgZm9yIHByb2dyYW1zLgogQUNfUFJPR19DQwogQUNfUFJPR19JTlNUQUxMCkBAIC05LDEwICsx
NSwxMCBAQAogQUNfU1lTX0xBUkdFRklMRQogCiAjIFRoYW5rcyB0byBNYXJ0aW4gUG9vbAotaWYg
dGVzdCB4IiRHQ0MiID0geHllcyAKK2lmIHRlc3QgeCIkR0NDIiA9IHh5ZXMgJiYgdGVzdCB4IiRE
RUZBVUxUX0NGTEFHUyIgIT0geAogdGhlbgogICAgIENGTEFHUz0iLWcgLVdhbGwgLU8zIgotICAg
IEFDX01TR19OT1RJQ0UoW1NldHRpbmcgZ2NjIG9wdGlvbnM6ICRDRkxBR1NdKQorICAgIEFDX01T
R19SRVNVTFQoW1NldHRpbmcgZGVmYXVsdCBjZmxhZ3M6ICRDRkxBR1NdKQogZmkKIAogQUNfQ0hF
Q0tfSEVBREVSUyhmY250bC5oIHN5cy90aW1lLmggc3lzL3VuaXN0ZC5oIHVuaXN0ZC5oKQpAQCAt
NDUsMTIgKzUxLDggQEAKIEFDX0NIRUNLX0xJQihiejIsIEJaMl9iekJ1ZmZUb0J1ZmZDb21wcmVz
cywgLCAKICAgICAgICAgQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCBiejIgbGlicmFyeSAt
IHBsZWFzZSBpbnN0YWxsIGxpYmJ6Mi1kZXZlbF0pKQogCi1lY2hvICRhY19uICJjaGVja2luZyBm
b3IgZXJybm8gaW4gZXJybm8uaC4uLiAkYWNfYyIKLUFDX1RSWV9DT01QSUxFKFsjaW5jbHVkZSA8
ZXJybm8uaD5dLFtpbnQgaSA9IGVycm5vXSwKLWVjaG8geWVzOyBBQ19ERUZJTkUoSEFWRV9FUlJO
T19ERUNMKSwKLWVjaG8gbm8pCi0KIEFDX0NIRUNLX0ZVTkNTKG1tYXAgc3RyZXJyb3IpCiBBQ19D
SEVDS19GVU5DUyhnZXRvcHRfbG9uZykKK0FDX0NIRUNLX0ZVTkNTKHN0cm5kdXApCiAKIEFDX09V
VFBVVChNYWtlZmlsZSkKZGlmZiAtciAtdU4gcnppcC0yLjEvbWFpbi5jIHJ6aXAtMi4xLXBhdGNo
ZWQvbWFpbi5jCi0tLSByemlwLTIuMS9tYWluLmMJMjAwNi0wMi0xNCAwMTozODoyMy4wMDAwMDAw
MDAgKzAxMDAKKysrIHJ6aXAtMi4xLXBhdGNoZWQvbWFpbi5jCTIwMDgtMDctMjcgMjI6MDA6Mjgu
Mjk4MDcxMjA3ICswMjAwCkBAIC0xOCw2ICsxOCw3IEBACiAvKiByemlwIGNvbXByZXNzaW9uIC0g
bWFpbiBwcm9ncmFtICovCiAKICNpbmNsdWRlICJyemlwLmgiCisjaW5jbHVkZSAic3RydXRpbHMu
aCIKIAogc3RhdGljIHZvaWQgdXNhZ2Uodm9pZCkKIHsKZGlmZiAtciAtdU4gcnppcC0yLjEvTWFr
ZWZpbGUuaW4gcnppcC0yLjEtcGF0Y2hlZC9NYWtlZmlsZS5pbgotLS0gcnppcC0yLjEvTWFrZWZp
bGUuaW4JMjAwNi0wMi0xNCAwMTozODoyMy4wMDAwMDAwMDAgKzAxMDAKKysrIHJ6aXAtMi4xLXBh
dGNoZWQvTWFrZWZpbGUuaW4JMjAwOC0wNy0yNyAyMTo1ODowOC4yMDE0MTk3OTAgKzAyMDAKQEAg
LTMsOCArMyw4IEBACiAKIHByZWZpeD1AcHJlZml4QAogZXhlY19wcmVmaXg9QGV4ZWNfcHJlZml4
QAotSU5TVEFMTF9CSU49JChleGVjX3ByZWZpeCkvYmluCi1JTlNUQUxMX01BTj0kKHByZWZpeCkv
bWFuCitJTlNUQUxMX0JJTj0kKERFU1RESVIpL0BiaW5kaXJACitJTlNUQUxMX01BTj0kKERFU1RE
SVIpL0BtYW5kaXJACiAKIExJQlM9QExJQlNACiBDQz1AQ0NACkBAIC0yMCw3ICsyMCw3IEBACiAu
U1VGRklYRVM6CiAuU1VGRklYRVM6IC5jIC5vCiAKLU9CSlM9IHJ6aXAubyBydW56aXAubyBtYWlu
Lm8gc3RyZWFtLm8gdXRpbC5vIGNyYzMyLm8KK09CSlM9IHJ6aXAubyBydW56aXAubyBzdHJ1dGls
cy5vIG1haW4ubyBzdHJlYW0ubyB1dGlsLm8gY3JjMzIubwogCiAjIG5vdGUgdGhhdCB0aGUgLUku
IGlzIG5lZWRlZCB0byBoYW5kbGUgY29uZmlnLmggd2hlbiB1c2luZyBWUEFUSAogLmMubzoKQEAg
LTM1LDYgKzM1LDcgQEAKIAkke0lOU1RBTExDTUR9IC1tIDc1NSByemlwICR7SU5TVEFMTF9CSU59
CiAJLW1rZGlyIC1wICR7SU5TVEFMTF9NQU59L21hbjEKIAkke0lOU1RBTExDTUR9IC1tIDY0NCAk
KHNyY2RpcikvcnppcC4xICR7SU5TVEFMTF9NQU59L21hbjEvCisJbG4gLXMgcnppcCAkKElOU1RB
TExfQklOKS9ydW56aXAKIAogcnppcDogJChPQkpTKQogCSQoQ0MpICQoQ0ZMQUdTKSAtbyByemlw
ICQoT0JKUykgJChMSUJTKQpkaWZmIC1yIC11TiByemlwLTIuMS9yemlwLmggcnppcC0yLjEtcGF0
Y2hlZC9yemlwLmgKLS0tIHJ6aXAtMi4xL3J6aXAuaAkyMDA2LTAyLTE0IDAxOjM4OjIzLjAwMDAw
MDAwMCArMDEwMAorKysgcnppcC0yLjEtcGF0Y2hlZC9yemlwLmgJMjAwOC0wNy0yNyAyMTo1ODow
OC4yMDQ3NTI2MTcgKzAyMDAKQEAgLTk0LDcgKzk0LDcgQEAKICNkZWZpbmUgc3RyZXJyb3IoaSkg
c3lzX2Vycmxpc3RbaV0KICNlbmRpZgogCi0jaWZuZGVmIEhBVkVfRVJSTk9fREVDTAorI2lmICFk
ZWZpbmVkKGVycm5vKQogZXh0ZXJuIGludCBlcnJubzsKICNlbmRpZgogCmRpZmYgLXIgLXVOIHJ6
aXAtMi4xL3N0cnV0aWxzLmMgcnppcC0yLjEtcGF0Y2hlZC9zdHJ1dGlscy5jCi0tLSByemlwLTIu
MS9zdHJ1dGlscy5jCTE5NzAtMDEtMDEgMDE6MDA6MDAuMDAwMDAwMDAwICswMTAwCisrKyByemlw
LTIuMS1wYXRjaGVkL3N0cnV0aWxzLmMJMjAwOC0wNy0yNyAyMTo1ODowOC4yMDQ3NTI2MTcgKzAy
MDAKQEAgLTAsMCArMSwyOSBAQAorLyogCisgICBDb3B5cmlnaHQgKEMpIDIwMDUgR2VudG9vIEZv
dW5kYXRpb24KKyAgIAorICAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4g
cmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAgIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CisgICB0aGUgRnJl
ZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBv
cgorICAgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyAgIAorICAgVGhpcyBw
cm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWws
CisgICBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3
YXJyYW50eSBvZgorICAgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxB
UiBQVVJQT1NFLiAgU2VlIHRoZQorICAgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1v
cmUgZGV0YWlscy4KKyAgIAorICAgWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAgIGFsb25nIHdpdGggdGhpcyBwcm9ncmFt
OyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisgICBGb3VuZGF0aW9uLCBJbmMu
LCA2NzUgTWFzcyBBdmUsIENhbWJyaWRnZSwgTUEgMDIxMzksIFVTQS4KKyovCisvKiBzdHJpbmcg
dXRpbGl0aWVzIHRoYXQgbWF5IGJlIG1pc3Npbmcgb24gdmFyaW91cyBwbGF0Zm9ybXMgKi8KKwor
I2luY2x1ZGUgInN0cnV0aWxzLmgiCisKKyNpZm5kZWYgSEFWRV9TVFJORFVQCitjaGFyKiBzdHJu
ZHVwKGNvbnN0IGNoYXIqIHMsIHNpemVfdCBuKSB7CisJY2hhciogcmV0ID0gbWFsbG9jKG4gKyAx
KTsKKwlpZiAocmV0ID09IE5VTEwpIHJldHVybihyZXQpOworCXJldFtuXSA9ICdcMCc7CisJcmV0
dXJuKG1lbWNweShyZXQsIHMsIG4pKTsKK30KKyNlbmRpZgpkaWZmIC1yIC11TiByemlwLTIuMS9z
dHJ1dGlscy5oIHJ6aXAtMi4xLXBhdGNoZWQvc3RydXRpbHMuaAotLS0gcnppcC0yLjEvc3RydXRp
bHMuaAkxOTcwLTAxLTAxIDAxOjAwOjAwLjAwMDAwMDAwMCArMDEwMAorKysgcnppcC0yLjEtcGF0
Y2hlZC9zdHJ1dGlscy5oCTIwMDgtMDctMjcgMjE6NTg6MDguMjA0NzUyNjE3ICswMjAwCkBAIC0w
LDAgKzEsMzEgQEAKKy8qIAorICAgQ29weXJpZ2h0IChDKSAyMDA1IEdlbnRvbyBGb3VuZGF0aW9u
CisgICAKKyAgIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJp
YnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgICBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBH
ZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorICAgdGhlIEZyZWUgU29mdHdh
cmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IKKyAgIChh
dCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgICAKKyAgIFRoaXMgcHJvZ3JhbSBp
cyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICAgYnV0
IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkg
b2YKKyAgIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T
RS4gIFNlZSB0aGUKKyAgIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFp
bHMuCisgICAKKyAgIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBH
ZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgICBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90
LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQorICAgRm91bmRhdGlvbiwgSW5jLiwgNjc1IE1h
c3MgQXZlLCBDYW1icmlkZ2UsIE1BIDAyMTM5LCBVU0EuCisqLworLyogc3RyaW5nIHV0aWxpdGll
cyB0aGF0IG1heSBiZSBtaXNzaW5nIG9uIHZhcmlvdXMgcGxhdGZvcm1zICovCisKKyNpZm5kZWYg
X0hFQURFUl9TVFJVVElMCisjZGVmaW5lIF9IRUFERVJfU1RSVVRJTCAxCisKKyNpbmNsdWRlIDxz
dGRsaWIuaD4KKyNpbmNsdWRlIDxzdHJpbmcuaD4KKyNpbmNsdWRlICJjb25maWcuaCIKKworIyBp
Zm5kZWYgSEFWRV9TVFJORFVQCitjaGFyKiBzdHJuZHVwKGNvbnN0IGNoYXIqIHMsIHNpemVfdCBu
KTsKKyMgZW5kaWYKKworI2VuZGlmCg==
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>161756</attachid>
            <date>2008-07-30 18:36 0000</date>
            <desc>Patch for rzip to enable uncompressing of archives created with the broken rzip.</desc>
            <filename>rzip-handle-broken-archive.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">ZGlmZiAtdXIgcnppcC0yLjEvbWFpbi5jIHJ6aXAtMi4xLXBhdGNoZWQvbWFpbi5jCi0tLSByemlw
LTIuMS9tYWluLmMJMjAwNi0wMi0xNCAwMTozODoyMy4wMDAwMDAwMDAgKzAxMDAKKysrIHJ6aXAt
Mi4xLXBhdGNoZWQvbWFpbi5jCTIwMDgtMDctMzAgMTk6Mjk6NDkuNDI2OTI2NzI2ICswMjAwCkBA
IC0zNSw2ICszNSw3IEBACiAJcHJpbnRmKCIgICAgIC1rICAgICAgICAgICAga2VlcCBleGlzdGlu
ZyBmaWxlc1xuIik7CiAJcHJpbnRmKCIgICAgIC1QICAgICAgICAgICAgc2hvdyBjb21wcmVzc2lv
biBwcm9ncmVzc1xuIik7CiAJcHJpbnRmKCIgICAgIC1MIGxldmVsICAgICAgc2V0IGNvbXByZXNz
aW9uIGxldmVsXG4iKTsKKwlwcmludGYoIiAgICAgLWwgbnIgICAgICAgICBzZXQgaGlnaGVyIGJp
dHMgb2YgdGhlIGV4cGVjdGVkIGZpbGUgbGVuZ3RoIHRvIG5yXG4iKTsKIAlwcmludGYoIiAgICAg
LVYgICAgICAgICAgICBzaG93IHZlcnNpb25cbiIpOwogI2lmIDAKIAkvKiBkYW1uLCB0aGlzIHdp
bGwgYmUgcXVpdGUgaGFyZCB0byBkbyAqLwpAQCAtMTcyLDYgKzE3MywxMyBAQAogCiAJCiAJcmVh
ZF9tYWdpYyhmZF9pbiwgZmRfb3V0LCAmZXhwZWN0ZWRfc2l6ZSk7CisKKyNpZmRlZiBIQVZFX0xB
UkdFX0ZJTEVTCisJaWYgKGNvbnRyb2wtPm5yKSB7CisJCWV4cGVjdGVkX3NpemUgPSAoICgob2Zm
X3QpKGNvbnRyb2wtPm5yKSk8PDMyKSB8IChleHBlY3RlZF9zaXplICYgMHhGRkZGRkZGRik7CisJ
fQorI2VuZGlmCisKIAlydW56aXBfZmQoZmRfaW4sIGZkX291dCwgZmRfaGlzdCwgZXhwZWN0ZWRf
c2l6ZSk7CQogCQogCWlmICgoY29udHJvbC0+ZmxhZ3MgJiBGTEFHX1RFU1RfT05MWSkgPT0gMCkg
ewpAQCAtMjY3LDcgKzI3NSw3IEBACiAJCWNvbnRyb2wuZmxhZ3MgfD0gRkxBR19ERUNPTVBSRVNT
OwogCX0KIAotCXdoaWxlICgoYyA9IGdldG9wdChhcmdjLCBhcmd2LCAiaDAxMjM0NTY3ODlkUzp0
VnZrZlBvOkw6IikpICE9IC0xKSB7CisJd2hpbGUgKChjID0gZ2V0b3B0KGFyZ2MsIGFyZ3YsICJo
MDEyMzQ1Njc4OWRTOnRWdmtsOmZQbzpMOiIpKSAhPSAtMSkgewogCQlpZiAoaXNkaWdpdChjKSkg
ewogCQkJY29udHJvbC5jb21wcmVzc2lvbl9sZXZlbCA9IGMgLSAnMCc7CiAJCQljb250aW51ZTsK
QEAgLTI5NSw2ICszMDMsMTIgQEAKIAkJY2FzZSAnayc6CiAJCQljb250cm9sLmZsYWdzIHw9IEZM
QUdfS0VFUF9GSUxFUzsKIAkJCWJyZWFrOworCQljYXNlICdsJzoKKyNpZm5kZWYgSEFWRV9MQVJH
RV9GSUxFUworCQkJZmF0YWwoIllvdSB1c2VkIHRoZSAtbCBvcHRpb24sIGJ1dCB0aGlzIHJ6aXAg
ZG9lc24ndCBzdXBwb3J0IGxhcmdlIGZpbGVzLiIpOworI2VuZGlmCisJCQljb250cm9sLm5yID0g
YXRvaShvcHRhcmcpOworCQkJYnJlYWs7CiAJCWNhc2UgJ3YnOgogCQkJY29udHJvbC52ZXJib3Np
dHkrKzsKIAkJCWJyZWFrOwpkaWZmIC11ciByemlwLTIuMS9ydW56aXAuYyByemlwLTIuMS1wYXRj
aGVkL3J1bnppcC5jCi0tLSByemlwLTIuMS9ydW56aXAuYwkyMDAzLTEwLTA4IDAwOjA4OjI4LjAw
MDAwMDAwMCArMDIwMAorKysgcnppcC0yLjEtcGF0Y2hlZC9ydW56aXAuYwkyMDA4LTA3LTMwIDE5
OjM0OjAzLjgwMzU2NDA4NiArMDIwMApAQCAtMTc5LDEwICsxNzksMTYgQEAKICAqLwogb2ZmX3Qg
cnVuemlwX2ZkKGludCBmZF9pbiwgaW50IGZkX291dCwgaW50IGZkX2hpc3QsIG9mZl90IGV4cGVj
dGVkX3NpemUpCiB7Ci0Jb2ZmX3QgdG90YWwgPSAwOwotCXdoaWxlICh0b3RhbCA8IGV4cGVjdGVk
X3NpemUpIHsKLQkJdG90YWwgKz0gcnVuemlwX2NodW5rKGZkX2luLCBmZF9vdXQsIGZkX2hpc3Qp
OworCW9mZl90IHRvdGFsID0gMCwgZmluPTE7CisJd2hpbGUgKGZpbiAmJiB0b3RhbCA8IGV4cGVj
dGVkX3NpemUpIHsKKwkJZmluID0gcnVuemlwX2NodW5rKGZkX2luLCBmZF9vdXQsIGZkX2hpc3Qp
OworCQl0b3RhbCArPSBmaW47CiAJfQorCisJaWYgKHRvdGFsIDwgZXhwZWN0ZWRfc2l6ZSkgewor
CQlmcHJpbnRmKHN0ZGVyciwgIldhcm5pbmc6IFRoZSB1bmNvbXByZXNzZWQgc2l6ZSBkb2VzIG5v
dCBlcXVhbCB0aGUgZXhwZWN0ZWQgZmlsZSBzaXplLlxuSG93ZXZlciBpZiB5b3UgdXNlZCB0aGUg
LWwgb3B0aW9uLCB0aGlzIG1heSBiZSBva2F5LlxuIik7CisJfQorCiAJcmV0dXJuIHRvdGFsOwog
fQogCmRpZmYgLXVyIHJ6aXAtMi4xL3J6aXAuaCByemlwLTIuMS1wYXRjaGVkL3J6aXAuaAotLS0g
cnppcC0yLjEvcnppcC5oCTIwMDYtMDItMTQgMDE6Mzg6MjMuMDAwMDAwMDAwICswMTAwCisrKyBy
emlwLTIuMS1wYXRjaGVkL3J6aXAuaAkyMDA4LTA3LTMwIDE5OjI5OjQ5LjQyNjkyNjcyNiArMDIw
MApAQCAtMTEzLDYgKzExMyw3IEBACiAJdW5zaWduZWQgY29tcHJlc3Npb25fbGV2ZWw7CiAJdW5z
aWduZWQgZmxhZ3M7CiAJdW5zaWduZWQgdmVyYm9zaXR5OworCXVuc2lnbmVkIG5yOwogfTsKIAog
dm9pZCBmYXRhbChjb25zdCBjaGFyICpmb3JtYXQsIC4uLik7Cg==
</data>        

          </attachment>
    </bug>

</bugzilla>