On Mon 01 Feb, Dan Ingalls wrote:
I tried,
(FileStream fileNamed: 'zort') nextPutAll: 'Hello.'; close.
and it worked fine to create a new file in my local directory. The I tried,
(FileStream fileNamed: 'HD:Fun with 2.1:zort') nextPutAll: 'Hello.'; close.
Tried this on my Acorn and it failed both with fileNamed: 'ChangeSets/foo.b' and newFileNamed....
a) Tracing through was interesting and offers a couple of bugs for fixing:- StandardFileStream class>isAFileNamed: tests for the existence of a file by trying to open it. By using StandardFileStream>open:forWrite: it goes through several retries related to some changes Andreas made to do with registering etc. Assuming there is no better way to test for a file existing (looking in the directory _might_ be faster?) I suspect that changing #isAFileNamed: to avoid the retries might be useful.
b) Further, the debugger seems to have some problem with handling the [^nil] in #open:forWrite: - since the fileID is nil (the file does not exist) I rather expected to return through the block, but instead the debugger merrily stepped on to the next lines and then failed when trying to return to 'sender' which was, by then, nil. Seems like some problem with the return simulation? The code in BlockContext/ContextPart looks ok, and clearly got executed since the sender instvar was correctly nilled out. You can replicate this by (FileStream halt fileNamed: 'filepath of your chice') nextPutAll: 'Hello.'; close. and step/send down to StandardFileStream>open:forWrite:. Step over the #retryWithGC: and check that fileID is actually nil. Step over the [^nil] block and see how you do not follow the return. Continue stepping and the last return will fail due to a nil sender. Repeating the experiment but stepping over the send of #isAFileName: did not cause the debugger any trouble. I suspect there is something messed up in the Debugger updating, but I don't have enough energy today (flu) to follow it up all the way.
Also tried 'root/fullpathto/ChangeSets/foo.b' and had no problem. This makes me think that there may be differences in how our various VMs consider their paths (well, duh) and that we are not yet covering all the bases. David's original problem looks to me as if his machine is behaving rather like my Acorn in that the default directory for the OS is not neccessarily that where Squeak is living. If this is so, then attempting to open a file 'email\text.1' might be trying to find 'c:\email' rather than 'c:\squeakpath\email' or something like that. A simple fix to AcornFileDirectory>fullNameFor: has solved my problem and I suspect a similar change to DosFileDirectory>fullNameFor: would help. I can't explicitly suggest anything since I only have my Acorn around at the moment. Try checking the splitout path to see if it has a root character ($:) in it and if not, cat the directory's pathName with the splitout path and see if that helps.
tim