Take the 2-minute tour ×

It is my understanding that a .tar file contains directories and other files, and a .bz2 is a file that's compressed with bzip2 compression.

Therefore, most tarballs with bzip2 compression end in:


Which is bzip2 compression applied to a tarball.

However, whenever I download source code from a Mercurial webserver, either the internal one that you get from:

hg serve

Or from BitBucket, I get something that ends in


Which doesn't make sense to me, because you can't apply bzip2 compression on multiple files, which is why you need to "tar" them up first.

Is this a bug in Mercurial? Or is this a bug in my web browser (I've tried Google Chrome in Windows and Firefox in Ubuntu)? Or is this something that's just weird but doesn't make a difference?

The latest source that I downloaded was from http://bitbucket.org/bos/hgbook which is the repository for the Mercurial book.

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

I think I see the problem. The Content-Type header in the download is wonky:

% GET -Ssed http://host/mayorguard/archive/tip.tar.bz2
GET http://ry4an.org/hg/mayorguard/archive/tip.tar.bz2 --> 200 Script output follows
Connection: close
Date: Mon, 20 Sep 2010 19:01:00 GMT
Server: Apache/2.2.14 (Ubuntu)
Content-Type: application/x-tar
Client-Date: Mon, 20 Sep 2010 19:01:00 GMT
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
Content-Disposition: attachment; filename=mayorguard-dee99508cd77.tar.bz2

Notice the Content-Disposition header suggests the browser use a filename with the correct extension, but the Content-Type header says it's a .tar file. When I do that download in Google Chrome I get a resulting file named mayorguard-hashid.tar.gz.tar which isn't right.

The example above was from hgweb and the one below is from bitbucket:

% GET -Ssed http://bitbucket.org/mailchimp/etsy-php/get/000000000000.bz2
GET http://bitbucket.org/mailchimp/etsy-php/get/000000000000.bz2 --> 200 OK
Cache-Control: max-age=1800
Connection: close
Date: Mon, 20 Sep 2010 19:05:16 GMT
Accept-Ranges: bytes
Server: nginx/0.7.67
Content-Length: 189
Content-Type: application/x-tar
Expires: Mon, 20 Sep 2010 19:35:16 GMT
Last-Modified: Mon, 20 Sep 2010 19:05:16 GMT
Client-Date: Mon, 20 Sep 2010 19:05:16 GMT
Client-Response-Num: 1
Content-Disposition: attachment; filename=etsy-php-000000000000.bz2

I'd say that Mercurial is giving bad info and the browser is overthinking the filename.

share|improve this answer
That seems to make sense, but I'm no expert on HTTP. Is there a way to report this back to the Mercurial development team? –  pcd6623 Sep 20 '10 at 19:42
I sent a patch correcting the content types to their development list this afternoon. We'll see where it goes. –  Ry4an Sep 20 '10 at 22:04
Patch was accepted into mercurial today. It'll be in the next release. –  Ry4an Sep 27 '10 at 15:45
add comment

This is a bug in bitbucket, please report it to them: http://bitbucket.org/jespern/bitbucket/issues/new/

share|improve this answer
But the same thing happens with "hg serve", wouldn't that point to a more likely problem in Mercurial? I'm just speculating out loud. –  pcd6623 Sep 20 '10 at 18:41
I am using 1.6.3. When you hover over the links they appear normal, but when you actually download the file you get something else. I just did an "hg serve" on my local clone of the hgbook repository, and the file that I got was named hgbook-93154fbaae9b.tar.bz2.tar which is a little better than BitBucket, but still strange. –  pcd6623 Sep 20 '10 at 18:56
I've got the why of that in my answer. It's extension and Content-Type not matching so your browser "helps" by affixing the "right" extension for the Content-Type it's being told. –  Ry4an Sep 20 '10 at 21:12
add comment

Your Answer


