>> the only way to delete a string in a file is to copy the file up to
>> the slice, skip over the slice, and write the rest.
>
> It isn't necessary to copy the first part of the file. It's only
> necessary to rewrite from the cut to the end.
If the file is of any size, this can be very time-consuming, as you'll
be jittering the access arm one record at a time. Making a new file is
usually much faster, in practice, as the physical I/O can be done in
bursts. It is also recoverable, in the event of a crash.
Other solutions:
Use a database table, and delete the row.
Use some kind of indexed file, and delete the record.
Read the entire file into memory, manipulate it there, and rewrite.

Signature
John W. Kennedy
"Sweet, was Christ crucified to create this chat?"
-- Charles Williams. "Judgement at Chelmsford"
Roedy Green - 01 Mar 2008 19:17 GMT
On Fri, 29 Feb 2008 14:05:59 -0500, "John W. Kennedy"
<jwkenne@attglobal.net> wrote, quoted or indirectly quoted someone who
said :
>If the file is of any size, this can be very time-consuming, as you'll
>be jittering the access arm one record at a time. Making a new file is
>usually much faster, in practice, as the physical I/O can be done in
>bursts.
with the same size chunk buffer, it would be the same speed, unless
you had two different physical disks. You have the same arm jerking
back and forth.
The optimal size of the buffer is probably a lot bigger than the 1-8K
typically used in the olden days. I wish there were a way choosing
that size were automated, and customised to the particular machine.
It is silly for a machine with a 20 gigs of ram to fiddle around with
4K buffers.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
>It isn't necessary to copy the first part of the file. It's only
>necessary to rewrite from the cut to the end.
I lived on an island for a number of years where power would
go out very frequently. The battery backup did not always rescue you.
So my tendency is to avoid doing anything that if interrupted in mid
flight would destroy your file, like inplace file updates. I like to
create the new file, and only once it is ready, do the delete/rename.
That leaves only a tiny window of vulnerability.
Back in DOS days, when disks were tiny, but hairy-chested, I did a
lot of in place updating, including creating holes, and deleting. You
have to be careful how you do your slides, working bottom up or top
down to avoid overwriting. The same applies to in-ram sliding.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com