This is a resend, this time with the promised attachment!
________________
At 17:08 -0700 05/22/2002, John M McIntosh wrote:
having a repeatable test case would be nice.
Please try the attached SUnit tests. When I run them on Squeak 3.2.7Beta5 they fail, but on Squeak 3.0Alpha21MTCarbon they pass. This is using the same image in both cases.
Please let me know if you can reproduce this error.
What I think is going on is that once an attempt to open a file for reading has failed (e.g., because the file is not there), then all subsequent attempts to create new files for writing will fail.
The only slightly unusual thing about my setup is that the current directory has the Macintosh option-f (folder) character (asciiValue 196) as the final character of its name. However, this character has never caused a problem previously.
Andrew
On Saturday, May 25, 2002, at 03:48 Uhr, Andrew P. Black wrote:
Please try the attached SUnit tests. When I run them on Squeak 3.2.7Beta5 they fail, but on Squeak 3.0Alpha21MTCarbon they pass. This is using the same image in both cases.
These also pass in CocoaSqueak.
Marcel
-- Marcel Weiher Metaobject Software Technologies marcel@metaobject.com www.metaobject.com Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
At 13:02 +0200 05/26/2002, Marcel Weiher wrote:
On Saturday, May 25, 2002, at 03:48 Uhr, Andrew P. Black wrote:
Please try the attached SUnit tests. When I run them on Squeak 3.2.7Beta5 they fail, but on Squeak 3.0Alpha21MTCarbon they pass. This is using the same image in both cases.
These also pass in CocoaSqueak.
Do they fail for other people on Squeak 3.2.7Beta5? Or have I created some configuration weirdness?
Andrew
At 13:02 +0200 05/26/2002, Marcel Weiher wrote:
On Saturday, May 25, 2002, at 03:48 Uhr, Andrew P. Black wrote:
Please try the attached SUnit tests. When I run them on Squeak 3.2.7Beta5 they fail, but on Squeak 3.0Alpha21MTCarbon they pass. This is using the same image in both cases.
These also pass in CocoaSqueak.
Do they fail for other people on Squeak 3.2.7Beta5? Or have I created some configuration weirdness?
Andrew
Yes, it's the issue of the option-f in the folder or file name.
Also unless you have the AccuFonts loaded you can't display the option-f correctly in Squeak because the historical fonts don't map it correctly when we pull the name from the directory and convert to MacRoman.
This is a resend, this time with the promised attachment!
At 17:08 -0700 05/22/2002, John M McIntosh wrote:
having a repeatable test case would be nice.
Please try the attached SUnit tests. When I run them on Squeak 3.2.7Beta5 they fail, but on Squeak 3.0Alpha21MTCarbon they pass. This is using the same image in both cases.
Well if you pass ascii > 127 to unix systems for characters in path names I'm not sure what the behavior should be. However a misunderstanding of how the ascii to unicode translations should go defeats this in the current Mac VMs.
I ask for filePath = CFStringCreateWithBytes(kCFAllocatorDefault, (UInt8 *)pathString,pathStringLength,kCFStringEncodingMacRoman,false);
where pathString contains ascii 196. But the resulting unicode CFString has ascii 192! MMm but later after ensuring all the path is correct and aliases resolved we convert to an ascii string using MacRoman and we get
"/Users/johnmci/Documents/Squeak3.2.7osx/build/check\304/TestFile0"
8r304 -> 196 base 10
That calls fopen which fails the open because of the 8r304
Ah, but it seems I need to lie here. Instead of converting to MacRoman I need to convert to kCFStringEncodingUTF8 which then allows me to fool with the unicode aware file system yet use an ascii representation for the fopen
This of course isn't an issue with 3.0 because we deal with a different execution path and the old apis which allow ascii 196.
So I'll look into fixing in the next revision
This bug is fixed in a 3.2.7Beta6 mac VM I've put into the update process.
a) Fixed issue with high ascii characters in path names b) Fixed bug with some aliased path constructs (no bug reported, but found it in testing)
This is a resend, this time with the promised attachment!
At 17:08 -0700 05/22/2002, John M McIntosh wrote:
having a repeatable test case would be nice.
Please try the attached SUnit tests. When I run them on Squeak 3.2.7Beta5 they fail, but on Squeak 3.0Alpha21MTCarbon they pass. This is using the same image in both cases.
Please let me know if you can reproduce this error.
What I think is going on is that once an attempt to open a file for reading has failed (e.g., because the file is not there), then all subsequent attempts to create new files for writing will fail.
The only slightly unusual thing about my setup is that the current directory has the Macintosh option-f (folder) character (asciiValue 196) as the final character of its name. However, this character has never caused a problem previously.
Andrew
Attachment converted: Lamie:StdFileS.cs (TEXT/R*ch) (000BDDA4)
squeak-dev@lists.squeakfoundation.org
-
Andrew P. Black -
John M McIntosh -
Marcel Weiher