From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1FdFUh-0006Vp-V4
	for qemu-devel@nongnu.org; Mon, 08 May 2006 19:50:27 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1FdFUg-0006Vd-9V
	for qemu-devel@nongnu.org; Mon, 08 May 2006 19:50:27 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1FdFUf-0006Va-VD
	for qemu-devel@nongnu.org; Mon, 08 May 2006 19:50:26 -0400
Received: from [128.8.10.163] (helo=po1.wam.umd.edu)
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1FdFVc-0004f8-5Z
	for qemu-devel@nongnu.org; Mon, 08 May 2006 19:51:24 -0400
Received: from jbrown.mylinuxbox.org (jma-box.student.umd.edu [129.2.253.219])
	by po1.wam.umd.edu (8.12.11.20060308/8.12.10) with ESMTP id
	k48NoOFP014787
	for <qemu-devel@nongnu.org>; Mon, 8 May 2006 19:50:25 -0400 (EDT)
Date: Mon, 8 May 2006 19:50:24 -0400
From: "Jim C. Brown" <jma5@umd.edu>
Subject: Re: [Qemu-devel] Re: qemu disk on vfat
Message-ID: <20060508235024.GA18407@jbrown.mylinuxbox.org>
References: <1147218062.9211.2.camel@localhost>
	<Pine.LNX.4.44.0605082301510.18524-100000@zeskia.int.eridani.co.uk>
	<20060508224846.GA9668@jbrown.mylinuxbox.org>
	<20060508231032.GA12871@jbrown.mylinuxbox.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060508231032.GA12871@jbrown.mylinuxbox.org>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Aactually, the bug is in vfat not in qemu-img.

qemu-img correctly uses ftruncate() which is suppose to make the file sparse
if the underlying filesystem supports it, but it should fall back to adding zeros
to the end of the file. On vfat you aren't able to seek past the end of a file
period, so this doesn't work.

Probably qemu-img should just bail out in this case (as the other disk formats
should work fine and you can always use dd). The 2nd patch I released does
this - the error message just needs to be made more accurate.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.