Re: Modifying a file w/o creating a temp file
Joe Hudson wrote:
Hi,
I have a bit of text I want to replace in a file with some other
text. I am aware of how to do this by creating a temp file and
renaming the temp file to the original file name after processing.
However, I am trying to find a way to modify content of a file. Is
there any way I can do something like this file.replace(srcIndexStart,
srcIndexEnd, "replace text");
I know the method I gave is not on the java.io.class and, for that
matter, I would at least use an OutputStream to do this normally.
But, I am beginning to think that what I am looking for isn't an
option with Java. I very much appreciate any insight that someone
might be willing to offer. Thanks.
In the special case where the original text and the
replacement text are the same length[*], this is pretty
easy to do: Scan through the file looking for the search
text, and whenever you find it seek back to its starting
point and write the replacement. Then resume scanning
after the end of the replacement.
[*] Note that in the case of multi-byte character
encodings, two Java strings of identical length might
have different encoded "external" lengths.
If the replacement is shorter than the original, you
need to slide all the following material toward the front
of the file to squeeze out the gap, and when you're done
you'll need to lop off the tail end of the now-shorter
file. This is bad but could still be done in one pass
over the file, keeping track of an "accumulated deficit"
as you go and thus shifting each non-replaced span just
once instead of potentially many times. Another possibility
is to fill the gaps with a character like '\u0000' that the
users of your file agree to ignore if encountered.
If the replacement is longer, things get nasty. The
best in-place method I can think of would make one pass
through the file just counting the number of times the
search text appears and where each begins. Then there'd
be a second pass of shift-and-replace, working backwards
from the tail of the file toward the front.
My advice is to stick with the temporary file: The
code will be far simpler, you won't need to worry about
length-changing character encodings, and the program is
likely to run faster (except in the equal-length case or
the contract-with-padding case), because it won't have to
do all that jumping around and sliding back and forth.
(I've only encountered one file system that had direct
support for insert-in-the-middle or snip-from-the-middle
for sequential text files, and it was a very strange system.
Definitely not programmed in Java, nor in C++, nor even in C:
We did all our work in assembly, and we LIKED it, sorta.
Definitely a special-purpose system, not like anything I've
seen in the last couple decades.)
--
Eric.Sosman@sun.com