piranna / pyfilesystem

Automatically exported from code.google.com/p/pyfilesystem
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

FileWrapper.__del__ doesn't call FileWrapper.close #130

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Not sure if this is a bug or not, but thought I'd report it here in case it is 
;)

What steps will reproduce the problem?
>>> from fs.osfs import OSFS
>>> from fs.filelike import FileWrapper
>>> class FileWrapperSub(FileWrapper):
...     def __init__(self,wrapped_file,mode=None):
...             super(FileWrapperSub,self).__init__(wrapped_file,mode)
...             print "file %s was opened" % getattr(self, 'name', '')
...     def close(self):
...             super(FileWrapperSub,self).close()
...             print "file %s was closed" % getattr(self, 'name', '')
...
>>> myfs = OSFS('.')
>>> f = FileWrapperSub(myfs.open('testfile1', 'w'))
file \\?\D:\pyfilesystem\testfile1 was opened
>>> f.write('fish')
>>> f.close()
file \\?\D:\pyfilesystem\testfile1 was closed
>>> FileWrapperSub(myfs.open('testfile2', 'w')).write('cat')
file \\?\D:\pyfilesystem\testfile2 was opened
>>>

What is the expected output? What do you see instead?
I'd expect the last line to print
file \\?\D:\pyfilesystem\testfile2 was opened
file \\?\D:\pyfilesystem\testfile2 was closed

Instead, it doesn't print that the file got closed.

Please use labels and text to provide additional information.
It looks like FileWrapper.__del__ calls close on the base class (in this case 
FileLikeBase) and on the wrapped_file, but not on self. However I'm not 100% 
certain of what all the code in FileWrapper.__del__ is doing.

Feel free to close this as invalid if I've misunderstood this and the fix is 
for FileWrapperSub to simply override __del__ as well.

Original issue reported on code.google.com by gc...@loowis.durge.org on 2 Sep 2012 at 5:11

GoogleCodeExporter commented 9 years ago

Original comment by gc...@loowis.durge.org on 2 Sep 2012 at 5:12

GoogleCodeExporter commented 9 years ago
I haven't actually tested this, but I think because you are running this inside 
the interpreter that that your FileWrapperSub instance isn't actually going out 
of scope there. The interpreter keeps the result of the last command in a 
variable called '_', so there is still a reference to it after the last line.

If you put the code in a .py file and run it, I suspect it will work as you 
would expect. If it doesn't, then it must be a bug.

Original comment by willmcgugan on 3 Sep 2012 at 9:59

GoogleCodeExporter commented 9 years ago
Just tested it, and you're absolutely right, and it does look like __del__ 
doesn't call close on itself, only on FileWrapperBase and the wrapped file. But 
I think this may be intended behaviour. Best to run it by Ryan to be sure.

Original comment by willmcgugan on 3 Sep 2012 at 10:32

GoogleCodeExporter commented 9 years ago
IIRC, __del__ bypasses self.close() so that it can be sure that 
self.wrapped_file is cleaned up properly, even if there happen to be errors in 
the file wrapper itself.

Given that python will close self.wrapped_file when it's garbage collected 
anyway, this may not be a valid concern.  Just calling self.close() would 
certainly simplify the code in FileWrapper.__del__.

Original comment by rfkel...@gmail.com on 3 Sep 2012 at 10:03