Another bug in NSIS 1.64 ???

Another bug in NSIS 1.64 ???
My last thread was about reading textfiles.
It appeared that there might be a bug in FileRead,
because I tried to use the errorflag to escape from
a reading loop, but that did not work.

Actually, I'm trying to write an installation that will
add some lines to a startup (text)file.
At Uninstall, these lines should be deleted from that
file of course. So I've written a procedure that will
read the file untill the end (thx Dave!!!) and I will
write this line into another temp file unless the line
corresponds to the line added by the Install. (Lateron I
delete the original file and rename the tempfile).

But I discovered that if there is no EndOfLine ("$\r$\n")
at the last line of the file, then FileWrite will write a
string to file with the last character repeated a lot of times:

Hi, my name is Smile2Meeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
(and more, in total 1024 characters)

Is this a bug??? How to avoid it???

Or: How to delete these lines from the file more easily???

Does anyone know???

Tell me please, thx, Hendri (:( Smile2Me)

Remark
I'm thinking that the problem above is still caused
by the same bug I encountered previously: FileRead
does not handle a EOF properly if it occurs before
an EOL (is my opinion, Justin help me, please!)

The reason: the strings I write to a new file are
produced by FileRead, so that should be the cause.

Code so far:
function "copyandleaveout"
FileOpen $0 "ReadingFile" "r"
FileOpen $1 "WritingFile" "w"
loop:
FileRead $0 $2
StrCmp $2 "" Exit
StrCmp $2 "This line should be left out$\r$\n" loop
FileWrite $1 $2
Goto loop
Exit:
FileClose $0
FileClose $1
FunctionEnd

and this produces a textfile without the line that should be
left out, but the last line of the produced text file is really
weird (see above), e.g.:
Hi, my name is Smile2Meeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
where the original file had as a last line:
Hi, my name is Smile2Me

So there seems to bee something wrong with FileRead,
because it does not generate the right string if EOF
is encountered and certainly not a proper error if I
try to read the file after EOF. (I used an IfErrors
construction before to escape from the loop, but it
actually did not escape from the loop, so I had to close
the UnInstall using Ctrl+Alt+Del...)

Justin (or anyone), does this sound familiar to you???
Am I doing something wrong or did I discover a bug???

Tell me, greetz, Hendri (:( Smile2Me).