Bug 106633 - fclose returns before it is all the way cleaned up..
Summary: fclose returns before it is all the way cleaned up..
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: glibc   
(Show other bugs)
Version: 2.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-08 23:15 UTC by Joe Baric
Modified: 2016-11-24 15:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-11 14:13:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Joe Baric 2003-10-08 23:15:35 UTC
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:

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.

Comment 1 Ulrich Drepper 2004-09-28 07:41:39 UTC
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.

Comment 2 Jakub Jelinek 2004-11-11 14:13:07 UTC
If you have more information, please reopen.

Note You need to log in before you can comment on or make changes to this bug.