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): glibc-2.2.4-32.3 kernel-2.4.9-e.24 How reproducible: Sometimes Steps to Reproduce: 1 fopen a good size file 2. use fgetc to read it all (or at least a good portion of it) 3. fclose 4. Immediately open the file (the program I worked with used open) Actual Results: open fails with -1 ETXTBUSY Expected Results: file opened correctly Additional info: 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.