I've lately been running into a problem with Vienna downloading files that appear as XXXX.dmg.bz which, when bunzipped, prove to have a corrupt dmg file. I simply assumed the files were indeed broken, and only investigated further when the number of occurrences seemed too high to be coincidence. It appears that the files downloaded did NOT originally have '.bz' in their filenames, Vienna's downloader appended the '.bz' itself as they were being downloaded.
A good example is <http://homepage.mac.com/aamann/files/MailScripts.dmg>.
Note that the server describes this file as content type '[application/octet-stream]', not '[application/x-apple-diskimage]' (as it should), but even so, the file should simply be downloaded 'as is'.
Also note that this particular dmg file is one with internal bzip2 compression:
hdiutil imageinfo MailScripts.dmg |grep Format
Format Description: UDIF read-only compressed (bzip2)
Manually bunzipping dmg files with internal bzip2 encoding doesn't work, since the dmg has its header info at the end, and this gets truncated from the resulting file as bzip2 regards it as garbage. The resulting dmg file is considered 'corrupt', and won't mount. [I normally avoid bzip2 compressed dmg files, since they cannot be read by Mac OS X 10.3.9 or earlier.]
Note that if you download the dmg file with any regular browser, the file does not get the '.bz' added on, and can be mounted as normal. Alternatively, if you remove the '.bz' from the end of the file, the file mounts correctly as well.
As an aside, note that the 'file' command incorrectly identifies the correctly downloaded dmg file as a bzip2 file:
MailScripts.dmg: bzip2 compressed data, block size = 100k
However, one cannot rely on 'file', as it is often mistaken. An example:
TheUnread1.1.dmg: VAX COFF executable - version 376
I think there is no question that the Vienna downloader should be fixed to avoid adding '.bz' onto these dmg files.