I found this bug using a python script that:

- first mounts a partition  (os.system("mount") etc)
- change a few files on this partition (f = open ();
f.write; f.close)
- umounts the partition (os.system("umount") etc)

Strangely, the umount didn't work because of a
filesystem busy error. Using fuser and lsof i traced
this being busy back to the script itself. This is
strange behavior because after changing the files on
the mounted partition the close method was called which
should close all references to the file on the partition. 

Finally the solution was to do f = 0. So if python has
closed a file on a mount a open reference to that file
will keep to exist until the script has ended or until
the file object is nullified.

Logged In: YES 
user_id=2772

I tried but can't reproduce this problem.

After mounting a filesystem on /mnt/tmp, I ran the following
in an interactive session:
>>> f = open("/mnt/tmp/x", "w")
>>> f.write("testing")
>>> f.close()
>>> import os; os.system("umount /mnt/tmp")
0

Did you write 'f.close()' or 'f.close'?  The former closes
the file, but the latter is a statement which has no effect.
 When you later executed 'f=0', the reference count of
the-old-value-of-f dropped to 0 and the file was close()d
impliclty.

Logged In: YES 
user_id=971153

I also failed to reproduce the problem with a recent Python
build on Debian (python session at the bottom)
 
Suggest closing the bug.

 bagira:~/python> dist/src/python
 Python 2.5a0 (#18, Jun  2 2005, 17:12:48) 
 [GCC 2.95.4 20011002 (Debian prerelease)] on linux2
 Type "help", "copyright", "credits" or "license" for more
information.
 >>> import os
 >>> os.system("mount /floppy")
 0
 >>> f=open("/floppy/test","w")
 >>> f.write('abcd')
 >>> f.close()
 >>> os.system('umount /floppy')
 0

Logged In: YES 
user_id=1188172

I think so too and close this as Invalid.

That the resources were freed when the file object was
cleaned up shows that the submitter must have made a mistake
since the destructor executes exactly the same code as close().