| Stephane CHAZELAS 2004-10-19, 2:48 am |
| Mail-Copies-To: nobody
Message-ID: <slrncn9egf.2ec.stephane.chazelas@spam.is.invalid>
User-Agent: slrn/0.9.8.0 (CYGWIN_NT-5.0)
Date: 19 Oct 2004 06:54:08 GMT
Lines: 31
Organization: Guest of ProXad - France
NNTP-Posting-Date: 19 Oct 2004 08:54:08 MEST
NNTP-Posting-Host: 195.152.231.98
X-Trace: 1098168848 news6-e.free.fr 29529 195.152.231.98:11577
X-Complaints-To: abuse@proxad.net
Xref: number1.nntp.dca.giganews.com comp.unix.internals:9773 comp.unix.admin:117989
2004-10-18, 20:33(-04), Barry Margolin:
> In article <slrncn75f3.2ec.stephane.chazelas@spam.is.invalid>,
> Stephane CHAZELAS <this.address@is.invalid> wrote:
>
>
> Is there a problem with this assumption? The usual objective is to
> optimize disk space. If the new file uses even less space than the
> original file, because the original had some real disk blocks that were
> all-zero, isn't that even *better* than reproducing the holes accurately?
[...]
Yes, especially when the system provides no way to find out
where the holes are, it can't do any arm to create ones, as no
application would ever rely on holes being or not being there.
I guess it would be possible to replicate the holes by altering
the original file (open the file read-write, test the first byte
of each block, if it's 0, then write(2) a zero then, do a
fstat(2) and check wether the number of blocks increases). But
that would involve actually filling all the holes in the
original file.
--
Stephane
|