[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] remark about http://www.freeoszoo.org

From: Karl Magdsick
Subject: Re: [Qemu-devel] remark about http://www.freeoszoo.org
Date: Mon, 4 Oct 2004 02:50:31 -0400

Free OS Zoo suggests using dd with the seek= option in the _specific_
case of Linux, which appears to be safe.  My comment was explicitly a
note of caution in the _general_ case. I did not intend to slander the
suggestions posted on the Free OS Zoo page.  My comments were meant
merely as a word of caution about over-generalizing the suggestions of
the Free OS Zoo people.

Perhaps I should have been more clear about the "in the general case"
part of my statement.  I meant "general" in the sense of making as few
extra assumptions as possible, not in the sense of "common".

Unless I had specific knowledge about sparse file support on my
filesystem and the behavior of fseek, lseek, llseek, etc. seeking past
the end of a file that cannot become sparse on my system, I would not
risk personal information on assumptions about the behavior of my
system.  Documentation of this behavior is spotty at best.  (Solaris
and Linux manpages, as well as the latest edition of Advanced
Programming in the UNIX Environment, implicitly assume that sparse
files are available across the board.)

In the specific case where you are using a filesystem that supports
sparse files (ext2, ext3, ufs, ffs, ntfs, etc.), seeking past the end
of the file is well documented and will create a sparse file, and
everything will be dandy.  HFS+ does not support sparse files, but OS
X zeroes out blocks as the seeks force their allocation on HFS+
partitons.  The latest Debian-testing for x86 will cause seeks past
the end of files on VFAT filesystems to fail, but this is not evident
from the documentation.  Therefore, for 99% of QEMU users, the
suggested method is probably safe.

I hereby apologise to anyone that feels I have over-stated the risks
involved in using dd to seek past the end of a file on arbitrary
filesystems and arbitrary OSes.  In the specific cases of ext2/ext3 on
Linux, NTFS on WinXP (cygwin or CoLinux), and HFS+/UFS on OS X, dd
will most likely behave correctly with the suggested inputs.  (I have
no personal experience with dd on WinXP.)  In the case of vfat
filesystems on Linux, the suggested method will fail in a safe manner,
leaking no information.

Sorry for any confusion,

On Sun, 3 Oct 2004 21:21:54 +0200, Lennert Buytenhek
<address@hidden> wrote:
> On Sun, Oct 03, 2004 at 01:47:00PM -0400, Karl Magdsick wrote:
> > To prevent this, in the dd command, use if=/dev/zero and change the
> > count to be the suggested seek value.  Do not specify a seek value.
> > This will cause dd to take longer to create a disk image, but it will
> > zero out the contents of the file, rather than asking the OS to create
> > a file from whatever garbage is left on disk.
> You think that "dd if=/dev/null of=blah bs=1024k count=1 seek=1024"
> creates a file that can have anything else than just zeroes in it,
> hm?
> Just try it.  And then please apologise to the freeoszee people.
> --L

reply via email to

[Prev in Thread] Current Thread [Next in Thread]