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

-- 
Useful random insult:- Enjoys listening to telemarketers.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>