Bug 106633 - fclose returns before it is all the way cleaned up..
fclose returns before it is all the way cleaned up..
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: glibc (Show other bugs)
2.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-08 19:15 EDT by Joe Baric
Modified: 2016-11-24 10:03 EST (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Joe Baric 2003-10-08 19:15:35 EDT
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.
Comment 1 Ulrich Drepper 2004-09-28 03:41:39 EDT
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 09:13:07 EST
If you have more information, please reopen.

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