[Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:]
>I did the rcsdiff, and it looks like it deals with the behavior when
>you seek
>beyond the end of the file. It simply writes zeros in 1024-byte chunks
>until the real eof catches up with the new eof.
Right. The newer GNU "ld" uses this to create its output executable files.
The older GNU "ld" didn't. It's at least one of the bugs hitting here.
>I could try to
>transplant this
>behavior to vstafs, but since this is really is supposed to create a
>sparse
>file, I am wondering if vstafs has a mechanism to deal with sparse
>files.
Nope, its data structures only represent densely allocated ones.
>All one would need to do is mark down the bytes skipped, and be sure to
>read in all zeros when that sparse block (or sparse extent, I guess) is
>read again.
And teach fsck the same thing, and also some complexity for messing around
with the buffer cache sizing when you grow data out into what was previously
sparse. I have never had much need for sparse files, and they also add
hassles for backup tools.
Anyway, I installed the tools on an older laptop, and see a problem running
"as" on it. From some A/B comparisons, it looks like the tail end of the
file got corrupt while copying it into the vstafs partition. I cp'ed the
file from the DOS server onto /tmp, and then cp'ed the same file from
vstafs, and although the have the same size, they differ in binary content
(cmp is your friend here). So vstafs either corrupted it while creating the
file, or while having it read() (my guess is the former).
Do you want to hunt it, or shall I? It'd be a good warm-up for implementing
sparse files. :-)
Andy
Received on Mon Oct 26 18:26:00 1998
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:55 PDT