Subject: Re: fileutils can now replace perforate...

From: Mark Eichin <[email-masked]>
Date: 06 Aug 1996 15:30:07 -0400

> But --sparse=auto is impossible to implement correctly on many
> systems, and filesystem-dependent on others !

Depends on what you mean by sparse...  the trick is that you can use
stat() to determine if the file has *any* holes.  If it has none, you
don't try to make new ones; if it already has some, you produce the
maximal amount. You may produce more sparseness than before -- but it
isn't like the application has any way to tell *where* the holes
are...

---

From: [email-masked] (Bernd Eckenfels)
Date: Wed, 7 Aug 1996 03:34:40 +0200 (MET DST)

Hello,

I have a question on that topic. I think sparse files are simply generated
by lseek'ing over a block of zeros, which will automatically converted to
sparse files by filesystems which support it (actually they could even
create them if the notice blocks filled with 0's but dont do it). The
question is, which filesystem generates sparse files and has problems with
it? Generally, wht is the problem with sparse files? They seem to be
completely transparent to me (except for cluttering the disk, perhaps).

Greetings
Bernd

---

From: Mark Eichin <[email-masked]>
Date: 06 Aug 1996 22:36:00 -0400

I don't know of any *unix* filesystems that have trouble with it.
There are some that simply don't support sparseness (like afs) and
lseeking will simply allocate actual blocks of zeros on the disk.

There was, at one point, a problem with one of the Sun bootloaders not
understanding sparse files, which is why you want an option to control
it (in gnu cp, it used to be the default and always on, which broke in
this case) but that's simply the bootloader having a bug, an
incomplete implementation.

---

From: Ian Jackson <[email-masked]>
Date: Fri, 9 Aug 96 21:16 BST

Mark Eichin writes ("Re: fileutils can now replace perforate..."):
> [Ian Jackson:]
> stat() to determine if the file has *any* holes.  

No, that's precisely what I'm claiming *can't* be done, because of
indirect blocks amongst other things.

IMO cp should either always produce sparse files by default or never
do so by default, not some half-way house that guesses and will get it
wrong sometimes.

Ian.