Red Hat Bugzilla – Bug 106633
fclose returns before it is all the way cleaned up..
Last modified: 2016-11-24 10:03:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR
1.0.3705; .NET CLR 1.1.4322)
Description of problem:
if you open a file with fopen, and then use getc to read a large portion of
that file. It will buffer those bytes in memory.
Then if you close and then immediately try to reopen the file the open cuold
fail with an ETXTBSY .
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1 fopen a good size file
2. use fgetc to read it all (or at least a good portion of it)
4. Immediately open the file (the program I worked with used open)
Actual Results: open fails with -1 ETXTBUSY
Expected Results: file opened correctly
I used gdb to set a breakpoint at the fclose and stepi'd through the fclose.
This gave time to the buffer to get cleaned up and then open worked fine.
I cannot reproduce this. In any case, a normal fopen() + fgetc() will
sequentially read parts of the file into memory. Nothing special.
And the fclose () does nothing but close the file descriptor and free
the buffer. Nothing which keeps a state at userlevel.
I do not know when the kernel generates ETXTBUSY but there is nothing
the userlevel code can do to avoid it. After the close syscall
returns userland knows nothing about the file.
It would help if you could provide strace output and a test program.
Maybe your description was not clear enough. Then we can see whether
this is something the kernel should handle better or not.
If you have more information, please reopen.