git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: madmarcos <fru574@my.utsa.edu>
To: git@vger.kernel.org
Subject: Java Inflater problem decompressing packfile
Date: Fri, 15 Apr 2011 19:05:05 -0700 (PDT)	[thread overview]
Message-ID: <1302919505984-6278154.post@n2.nabble.com> (raw)

This may be better suited for the Java forums but I will ask it here just in
case someone has run into it before.

I have a packfile that I have saved as a file from the git-upload-pack
command. I want to read through the packfile, decompressing each of the
objects. 

My little inflater procedure works fine for a tiny HelloWorld project. So, I
decided to mix it up a little and use the jEdit source for a larger test. I
am 99% certain the jEdit.git packfile itself is ok as I have passed it
through directly to eGit's Import using an SSH proxy and eGit unpacked it
just fine.

So, my inflater method decompresses the first 7 objects fine (a commit, a
couple of trees, and several blobs) and a cursory visual inspection of the
decompressed data seems fine. The eighth object becomes a problem, though.
It is a blob with the name build.xml that is 51,060 bytes decompressed
(looking at the original pre-git-pushed jEdit source). The actual file size
matches the decompressed data content size in the packfile object header. 
The inflater procedure outputs the decompressed data to System.out for
visual inspection. Approximately the first 1/3 looks like the original
build.xml but after that, the output is garbled. The procedure continues
decompressing objects after the 8th, but garbled, object but it dies on the
9th object with an "unknown compression method" error.

So I created a new test inflater to focus only on decompressing the 8th
object. Simply opening the packfile, copying out the compressed data (7793
bytes), and inflating it yields the same 2/3 garbled xml. 

As a further test, I then take the original build.xml file, compress it
using java's Deflater (yielding a 7793 byte array), and then inflate it
using my same procedure and it decompresses fine. All of the xml is
readable.

Now, I have tried several variations of an inflater procedure, including an
patchwork variation from jGit's WindowCursor.inflate method. But they all
yield the same garbled result for the compressed build.xml data.

Any suggestions. I can post some of my ugly code if asked.

Thanks!

--
View this message in context: http://git.661346.n2.nabble.com/Java-Inflater-problem-decompressing-packfile-tp6278154p6278154.html
Sent from the git mailing list archive at Nabble.com.

             reply	other threads:[~2011-04-16  2:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-16  2:05 madmarcos [this message]
2011-04-16  6:37 ` Java Inflater problem decompressing packfile Jeff King
2011-04-16 14:23   ` madmarcos
2011-04-16 14:36     ` madmarcos
2011-04-16 14:58       ` madmarcos
2011-04-16 15:50         ` madmarcos
2011-04-17  0:40           ` madmarcos
2011-04-17  4:02             ` madmarcos
2011-04-17  4:06               ` madmarcos
2011-04-17  4:36     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1302919505984-6278154.post@n2.nabble.com \
    --to=fru574@my.utsa.edu \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).