From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DMUCb-0004ks-Cs for qemu-devel@nongnu.org; Fri, 15 Apr 2005 13:01:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DMUCZ-0004kO-7e for qemu-devel@nongnu.org; Fri, 15 Apr 2005 13:01:55 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DMU9X-0003m2-T8 for qemu-devel@nongnu.org; Fri, 15 Apr 2005 12:58:47 -0400 Received: from [217.65.98.56] (helo=shiva.galaktik.hu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DMTx7-0002lm-Mk for qemu-devel@nongnu.org; Fri, 15 Apr 2005 12:45:57 -0400 Received: from [10.0.0.201] (helo=caprice.artificis.hu) by shiva.galaktik.hu with esmtp (Exim 3.35 #1 (Debian)) id 1DMVc3-0000Pv-00 for ; Fri, 15 Apr 2005 20:32:19 +0200 Date: Fri, 15 Apr 2005 18:47:58 +0200 From: Alex Beregszaszi Subject: Re: [Qemu-devel] [PATCH] Better .dmg autodetection Message-Id: <20050415184758.0b831c1c@caprice.artificis.hu> In-Reply-To: <1113339106.28622.196.camel@rapid> References: <20050412192841.03d16475@caprice.artificis.hu> <1113339106.28622.196.camel@rapid> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, > > There are quiet lot fake dmg files floating around. These are just > > raw images containing the Apple partition map and HFS partitions. > > Those are not fake dmg. > With Apple disk utility, you are free to choose if the dmg is to be > compressed or not. > Then, uncompressed dmg are valid ones. > But, you don't need to manage them in block-dmg,c as those are just > raw images... I spoke about better _autodetection_. Right now if it finds the .dmg extension, the file will be threaten as DMG, and it will fail if I throw an uncompressed one at it. > > * last check if the filename ends in .dmg > > It seems to me that this check is not to be done. > There's no need to. If the first sector (after decompression, if > needed) is a valid Apple partition map _or_ a valid partition entry > (ie with PM magic at start), then it's a valid dmg. File extensions > never mean anything, they are just a user-interface oriented > remainder, imho. Dont forget that the current implementations relies only on the file extension... Wrong, if it starts with ER (disk header) or PM, it is definitely an uncompressed file, thus it should be used via the raw interface. But if the first bytes resemble the zlib compression, it is definitely a dmg file which should be handled inside block-dmg. -- Alex Beregszaszi e-mail: alex@fsn.hu Free Software Network cell: +36 70 3144424