I'm having problems deleting a file after closing its file stream and it seems to be described in this thread http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-February/074560..... A gc seems to fix it. Is there a way to explicitly close it *immediately*? Thanks.
On Tue, Dec 28, 2004 at 04:13:06PM +0800, Yar Hwee Boon wrote:
I'm having problems deleting a file after closing its file stream and it seems to be described in this thread http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-February/074560..... A gc seems to fix it. Is there a way to explicitly close it *immediately*? Thanks.
Yes there is a way.
StandardFileStream>>finalize is what closes the file when the garbage collector runs, but this is not the way you would normally want to close the resource. It's just sort of the method of last resort if you did not remember to close the file explicitly.
StandardFileStream>>close is the method that closes the file cleanly and makes sure that the external file handle gets closed. If you use this to explicitly close all file streams that refer to the file, you should then be able to delete the file.
Both #finalize and #close will call the same #primitiveFileClose method (which you can find in class FilePlugin if you have VMMaker loaded). So just use #close on any open file streams connected to the file, all should be well.
Dave
On Tue, 28 Dec 2004 11:29:35 -0500, David T. Lewis lewis@mail.msen.com wrote:
StandardFileStream>>close is the method that closes the file cleanly and makes sure that the external file handle gets closed. If you use this to explicitly close all file streams that refer to the file, you should then be able to delete the file.
Thanks. I was clear enough. What I mean was after I close the file stream by sending #close, the file is not close immediately. For eg. if I check by sending #closed to the stream immediately after sending #close, it _sometimes_ answer false. But if I do a gc, or put a self halt than click proceed immediately when I see the debugger window, it will be ok. I can't rule out the possibility that its a bug in my code, but it certainly seems that #close does not work as you described. BTW, this is on windows.
On Wed, 29 Dec 2004 00:44:16 +0800, Yar Hwee Boon hboon@motionobj.com wrote:
On Tue, 28 Dec 2004 11:29:35 -0500, David T. Lewis lewis@mail.msen.com wrote:
StandardFileStream>>close is the method that closes the file cleanly and makes sure that the external file handle gets closed. If you use this to explicitly close all file streams that refer to the file, you should then be able to delete the file.
Thanks. I was clear enough. What I mean was after I close the file
Of course, I meant to say "I wasn't clear enough". No disrespect intended.
On Wed, Dec 29, 2004 at 12:44:16AM +0800, Yar Hwee Boon wrote:
On Tue, 28 Dec 2004 11:29:35 -0500, David T. Lewis lewis@mail.msen.com wrote:
StandardFileStream>>close is the method that closes the file cleanly and makes sure that the external file handle gets closed. If you use this to explicitly close all file streams that refer to the file, you should then be able to delete the file.
Thanks. I was clear enough. What I mean was after I close the file stream by sending #close, the file is not close immediately. For eg. if I check by sending #closed to the stream immediately after sending #close, it _sometimes_ answer false. But if I do a gc, or put a self halt than click proceed immediately when I see the debugger window, it will be ok. I can't rule out the possibility that its a bug in my code, but it certainly seems that #close does not work as you described. BTW, this is on windows.
Oh, I see. Perhaps this is Windows specific behavior. I don't have a Windows box at hand, but on Linux if I do this:
(1 to: 1000) collect: [:e | (FileStream fileNamed: 'junk.txt') close closed]
I get an array of all true. Do you get some false results in the array when you do it on your system?
Dave
On Tue, 28 Dec 2004 12:20:15 -0500, David T. Lewis lewis@mail.msen.com wrote:
Oh, I see. Perhaps this is Windows specific behavior. I don't have a Windows box at hand, but on Linux if I do this:
(1 to: 1000) collect: [:e | (FileStream fileNamed: 'junk.txt') close closed]
I get an array of all true. Do you get some false results in the array when you do it on your system?
Nope. I get all true too. I had a sunit test case for my code where I could reproduce it every time. But when I tried reproducing it in a workspace it was particularly elusive. I'll see if I can simplify the sunit test case, which currently uses 3 file streams concurrently and does a cycle of open-close-open-close. Was hoping if anyone had seen the problem :) Thanks.
See if you can find a tool that monitors the files that are open to let you check which files are the problem. I have one but it's for RISC OS which is unlikely to help you...
A potential problem here is that the Squeak idea of a FileStream doesn't map very tightly to the OS' idea. If you open the same file n times for example (and it's platform dependent to some degree) and close it n-1 times then obviously the OS will consider it open and behave somewhat differently than if it is _really_ closed.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Remember the good old days, when CPU was singular?
On Thu, 30 Dec 2004 10:58:09 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
See if you can find a tool that monitors the files that are open to let you check which files are the problem. I have one but it's for RISC OS which is unlikely to help you...
I'm using Sysinternals' Process Explorer. Great set of utilities from them for developers on windows. It does confirm that the file that are open. I'll just have to put it down to, probably some silly mistake I'm making or like you had suggested, a platform mismatch/oddity. Thanks for the suggestions.
"Yar Hwee Boon" hboon@motionobj.com wrote: To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Thursday, December 30, 2004 8:28 PM Subject: Re: StandardFileStream not closing files immediately
On Thu, 30 Dec 2004 10:58:09 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
See if you can find a tool that monitors the files that are open to let you check which files are the problem. I have one but it's for RISC OS which is unlikely to help you...
I'm using Sysinternals' Process Explorer. Great set of utilities from them for developers on windows.
Yes, a beautiful tool. Regrettably, I experienced problems when I ran it on a Windows 98 system.
It does confirm that the file that are open. I'll just have to put it down to, probably some silly mistake I'm making or like you had suggested, a platform mismatch/oddity. Thanks for the suggestions.
For simple file operations, I cannot confirm that a StandardFileStream is left open. However, we have methods that open files but never close them. Attached you find a test suite with 7 test examples. test6 fails because of wrong usage of a MimeDocument, but the other tests are ok for me. Can you please run these tests on your machine?
Also, I think that example code that runs into problems in your machine would help us to analyze possible problems.
Gretings, Boris
On Fri, 31 Dec 2004 12:35:54 +0100, Boris Gaertner Boris.Gaertner@gmx.net wrote:
Yes, a beautiful tool. Regrettably, I experienced problems when I ran it on a Windows 98 system.
Shouldn't be doing development on it anyway :) Guess there's no choice if you are doing testing.
Attached you find a test suite with 7 test examples. test6 fails because of wrong usage of a MimeDocument, but the other tests are ok for me. Can you please run these tests on your machine?
I'm getting the same result. Out of the 7 tests, only test6 fails.
Also, I think that example code that runs into problems in your machine would help us to analyze possible problems.
As soon as I can get the code back to the state it was in :)
It occurs to me that if you put a few Transcript show:'s in file open/closing methods _and_ use your monitoring tool to see which files the OS thinks are open and when, you might well find that you are not the only person opening the problem files.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Never write software that anthropomorphizes the machine. They hate that.
squeak-dev@lists.squeakfoundation.org