1. flush() bug?
Using the following program with exw.exe:
-----------------------------
include file.e
include get.e
integer fn
fn = open("test.txt","w")
puts(fn,"Hello")
close(fn)
? gets(0)
-------------------------------------------
The file "test.txt" is created and the console hangs until you hit enter. So
far so good. The file test.txt should be "unlocked" (because we close()'d it)
and it is -- I can move it, rename, etc with the console still open (so the
program hasn't terminated.)
If we change the middle section to:
-------------
fn = open("test.txt","w")
puts(fn,"Hello")
flush(fn)
close(fn)
-------------
It also works the same way, as expected.
However, if we do this:
--------------
fn = open("test.txt","w")
puts(fn,"Hello")
flush(fn)
puts(fn,"Hello")
close(fn)
--------------
The file test.txt now stays locked even though it has been closed -- it won't
release until we terminate the program. In other words, if we use flush() at any
point, and then write data to the file after the flush() and then close(), the
file stays locked.
The fix:
--------------
fn = open("test.txt","w")
puts(fn,"Hello")
flush(fn)
puts(fn,"Hello")
flush(fn)
close(fn)
--------------
We have to add an extra flush() before the close() to get it to release. An
easy fix, but still the behavior is not correct unless I'm missing something...
2. Re: flush() bug?
Andy Serpa wrote:
> Using the following program with exw.exe:
>
>
> -----------------------------
> include file.e
> include get.e
>
> integer fn
>
> fn = open("test.txt","w")
> puts(fn,"Hello")
> close(fn)
>
> ? gets(0)
>
> -------------------------------------------
> The file "test.txt" is created and the console hangs until you hit
> enter.
> So far so good. The file test.txt should be "unlocked" (because we
> close()'d it) and it is -- I can move it, rename, etc with the console
> still open (so the program hasn't terminated.)
<snip>
> However, if we do this:
>
> --------------
> fn = open("test.txt","w")
> puts(fn,"Hello")
> flush(fn)
> puts(fn,"Hello")
> close(fn)
> --------------
>
> The file test.txt now stays locked even though it has been closed -- it
> won't release until we terminate the program. In other words, if we
> use flush() at any point, and then write data to the file after the
> flush() and then close(), the file stays locked.
On my system (Windows 98) also the last program works as expected.
What Windows version do you use?
<snip>
Regards,
Juergen
--
Have you read a good program lately?
3. Re: flush() bug?
Juergen Luethje wrote:
>
> Andy Serpa wrote:
>
>
> On my system (Windows 98) also the last program works as expected.
> What Windows version do you use?
>
XP Pro. Please note that the output from the program is fine -- the file is
created, contains the correct stuff, etc. It is just that I can't do something
like rename the file manually or move it out of the folder where it is created
until the program terminates -- the OS says it is "in use by another program".
4. Re: flush() bug?
Actually, now I can't reproduce the error. The sample program was
cut-and-pasted after I verified the problem. Weird.
However, my larger program where I discovered the problem still has the problem
without the final flush() -- it is a db query program and dumps the output of
large queries to a file and then closes them. But the db client stays open and
the output file stays locked until I shut it down...
5. Re: flush() bug?
Andy Serpa wrote:
> Juergen Luethje wrote:
>>
>> Andy Serpa wrote:
>>
>> On my system (Windows 98) also the last program works as expected.
>> What Windows version do you use?
>>
> XP Pro. Please note that the output from the program is fine -- the
> file is created, contains the correct stuff, etc. It is just that I
> can't do something like rename the file manually or move it out of the
> folder where it is created until the program terminates -- the OS says
> it is "in use by another program".
Yep, that's what I was meaning. After the file is closed, I am able to
delete it, rename it manually, or move it to a different folder -- while
the Eu program that it created is still running.
Regards,
Juergen
6. Re: flush() bug?
Andy Serpa wrote:
>
> Using the following program with exw.exe:
>
>
> -----------------------------
> include file.e
> include get.e
>
> integer fn
>
> fn = open("test.txt","w")
> puts(fn,"Hello")
> close(fn)
>
> ? gets(0)
>
>
> -------------
> fn = open("test.txt","w")
> puts(fn,"Hello")
> flush(fn)
> close(fn)
>
> -------------
Carraige return after close(fn)?
>
> It also works the same way, as expected.
>
> However, if we do this:
>
> --------------
> fn = open("test.txt","w")
> puts(fn,"Hello")
> flush(fn)
> puts(fn,"Hello")
> close(fn)
> --------------
No carraige return ater close(fn)
>
> The file test.txt now stays locked even though it has been closed -- it won't
> release
> until we terminate the program. In other words, if we use flush() at any
> point, and
> then write data to the file after the flush() and then close(), the file stays
> locked.
>
> The fix:
>
> --------------
>
> fn = open("test.txt","w")
> puts(fn,"Hello")
> flush(fn)
> puts(fn,"Hello")
> flush(fn)
> close(fn)
>
> --------------
Carraige return after close(fn)?
>
> We have to add an extra flush() before the close() to get it to release. An
> easy fix,
> but still the behavior is not correct unless I'm missing something...
>
Just a thought. Last line in a file (script / interpreted) often needs a
carraige return
to be read correctly. I often had this problem when compiling C programs.
Chris
