bunzip2: (stdin): trailing garbage after EOF ignored - gaige--2008

You shouldn't be seeing .bz2 at all. We only distribute .dmg files (which have bz2-style compression internally, but that's not visible as an extension or in any other way externally to the user).

Try the link again. We've confirmed with multiple machines (intel and ppc) that the download link from VersionTracker, as well as the links from our site (http://www.cluetrust.com) are functioning.

Thanks,
-Gaige

Reply to This

Tuesday, April 04 2006 @ 03:40 AM PDT

bunzip2: (stdin): trailing garbage after EOF ignored - ttrtilley

I (with great support from the developer) have got it working.
Even though http://www.cluetrust.com/Downloads/LoadMyTracks.dmg
is a compressed disk image, downloading it with Safari appended a .bz2
qualifier to the name, so that I received a file called LoadMyTracks.dmg.bz2
Naturally I decompressed it before trying to mount it. :-(

All I had to do is remove the .bz2 with the Finder, and it "just worked".
Garmin eTrex Vista, Keyspan 19Qi, TiBook 800Mhz 1GB, OS X 10.4.5.
So nice to have all my waypoints in GoogleEarth.

Anyone else had this problem with Safari downloads????????
FireFox did the right thing, but Safari is not a bad browzer otherwise.
I have not seen this problem before, but prehaps most dmg's are
not compressed?

Reply to This

Wednesday, April 05 2006 @ 07:03 AM PDT

bunzip2: (stdin): trailing garbage after EOF ignored - ttrtilley

Hello Gaige ...

On my machine, in Terminal.app:
file LoadMyTracks.dmg
gives:
LoadMyTracks.dmg: bzip2 compressed data, block size = 100k

How about on your Mac???????

Most other .dmg files give either "data" or "VAX COFF executable ..." or "Apple Partition data ..."
Your's is the only one that gives "bzip2 ..." except for .bz2 files of course :-)

... Richard

Reply to This

Wednesday, April 05 2006 @ 08:06 AM PDT

bunzip2: (stdin): trailing garbage after EOF ignored - gaige--2008

It's an interesting question. It definitely shows that way on my machine as well, as does the .dmg for GraphicConverter (gc58xub.dmg).

However, the bytes in the beginning of a dmg file (those checked by file for "magic number") do not appear to be consistent for dmg files as a whole. Instead it seems to depend on the kind of compression in use on the disk image. In our case, we're using bzip2 compression (only supported by Tiger and beyond).

However, Disk Utiility will verify and mount the images fine on all of our test machines here.

You may want to download a copy of GraphicConverterX if you haven't just to see how it performs on your machine.

-Gaige

Reply to This

Thursday, April 06 2006 @ 02:15 AM PDT

bunzip2: (stdin): trailing garbage after EOF ignored - ttrtilley

Stranger and stranger.

GraphicConverter downloads and mounts fine, even though the first 10 bytes are the same as LoadMyTracks. "file" gives the same report for both files.
Neither file has a resource fork.
Both have the same permissions, blank TypeCreator, and unset Locked&Invisible flags.
Both have CreationDate=ModificationDate.
Must be either the FileName or other metadata, or something beyond the first 10 bytes!

The upgrade to 10.4.6 has made no difference.

Here is the nitty gritty:
rt:~/tmp/Safari rtilley$ mdls LoadMyTracks.dmg.bz2>/tmp/L
rt:~/tmp/Safari rtilley$ mdls gc*>/tmp/g
rt:~/tmp/Safari rtilley$ diff /tmp/L /tmp/g
1,5c1,5
< LoadMyTracks.dmg.bz2 -------------
< kMDItemAttributeChangeDate = 2006-04-06 22:36:02 +0800
< kMDItemContentCreationDate = 2006-03-23 04:37:33 +0800
< kMDItemContentModificationDate = 2006-03-23 04:37:33 +0800
< kMDItemContentType = "org.gnu.gnu-bzip2-tar-archive"
---
> gc581xub.dmg -------------
> kMDItemAttributeChangeDate = 2006-04-06 22:48:28 +0800
> kMDItemContentCreationDate = 2006-03-10 19:29:42 +0800
> kMDItemContentModificationDate = 2006-03-10 19:29:42 +0800
> kMDItemContentType = "com.apple.disk-image-udif"
7c7,9
< "org.gnu.gnu-bzip2-tar-archive",
---
> "com.apple.disk-image-udif",
> "com.apple.disk-image",
> "public.archive",
10c12
< "public.archive"
---
> "public.disk-image"
12,14c14,16
< kMDItemDisplayName = "LoadMyTracks.dmg.bz2"
< kMDItemFSContentChangeDate = 2006-03-23 04:37:33 +0800
< kMDItemFSCreationDate = 2006-03-23 04:37:33 +0800
---
> kMDItemDisplayName = "gc581xub.dmg"
> kMDItemFSContentChangeDate = 2006-03-10 19:29:42 +0800
> kMDItemFSCreationDate = 2006-03-10 19:29:42 +0800
20c22
< kMDItemFSName = "LoadMyTracks.dmg.bz2"
---
> kMDItemFSName = "gc581xub.dmg"
24c26
< kMDItemFSSize = 735095
---
> kMDItemFSSize = 18274014
26,33c28,32
< kMDItemID = 1745905
< kMDItemKind = "bzip2 compressed archive"
< kMDItemLastUsedDate = 2006-03-23 04:37:33 +0800
< kMDItemUsedDates = (2006-03-23 04:37:33 +0800)
< kMDItemWhereFroms = (
< "http://www.cluetrust.com/Downloads/LoadMyTracks.dmg",
< "http://www.versiontracker.com/dyn/moreinfo/macosx/29256"
< )
---
> kMDItemID = 1745840
> kMDItemKind = "disk image"
> kMDItemLastUsedDate = 2006-04-06 22:48:28 +0800
> kMDItemUsedDates = (2006-03-10 19:29:42 +0800, 2006-04-06 08:00:00 +0800)
> kMDItemWhereFroms = ("http://www.lemkesoft.org/files/gc581xub.dmg")


... Richard

Reply to This

Thursday, April 06 2006 @ 08:34 AM PDT

bunzip2: (stdin): trailing garbage after EOF ignored - gaige--2008

Well, the big problem is that the extension is being assigned by somebody. It's not on the files on our servers, and it isn't on the URL in versiontracker, so I'm not sure where it's coming from, but that's fooling LaunchServices into thinking that it's a true .bz2 file. Unfortunately, the way that the file's layout is structured, a bz2 compressed .dmg file may begin with the .bz2 magic bytes, which would cause it to be able to be decompressed, resulting in a file that has a .dmg extension, but is no longer a valid .dmg file.

Basically, the bunzip2 code will verify the magic number and if it checks (and the extension is bz2), it'll unzip the file, remove the .bz2 extension and place it on the disk. That's prevents problems if the .bz2 file doesn't have the magic number of doesn't have the extesion. In this case, the geometry of the .dmg file (which, when compressed, doesn't have its own magic number) is such that the first bytes are the same as the .bz2 file magic number. Makes sense, because the file is compressed with bz2. Unfortunately, this means that if, for some reason, the .dmg file is changed to .dmg.bz2, then it will end up with with something that will be linked by launch services to the BOMArchiver instead of the disk image loader and will also "successfully" decompress, leading to a bogus file.

In the end, the big problem is whatever is causing the .dmg file to have .bz2 appended to it. I'm curious that this happens consistently on your machine, not on others, but seems to be in some way related to the CFNetwork code (common between our autoupdater and Safari).

-Gaige

Reply to This

Friday, April 07 2006 @ 08:41 AM PDT

bunzip2: (stdin): trailing garbage after EOF ignored - josealvesfilho

Gostaria de saber mais sobre este programa. servirá para o mec e pc, mande-me maiores informações arespeito deste programa.ok Obrigado!
conato

86 88041983
josé alves filho
editor de fotografia do jornal meio norte
Teresina- Piauí- Brasil

Reply to This

Saturday, April 07 2007 @ 04:24 AM PDT