FileDirectory default is wrong in MacOS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

FileDirectory default is wrong in MacOS

Mariano Martinez Peck
Hi. The simplest way to find the problem (if my case it was muuuch more than this), I found the following:  MacOS is case insensitive (I've just figure it out). Since it is a UNIX at the end, I thought it was case sensitive, but it seems it is not. Now, suppose that in the directory where my image is, I have the file called 'zaraza'. If I evaluate this:

(FileDirectory default fileOrDirectoryExists: 'zaraza')  ->>>> true

I should get true. And the same with:


(FileDirectory default fileOrDirectoryExists: 'ZARAZA')  ->>>> false

But....I get false instead of true. Which is wrong in Mac OS.
The problem is that  FileDirectory default  -----> UnixFileDirectory

And this is because

FileDirectory class >> activeDirectoryClass
    "Return the concrete FileDirectory subclass for the platform on which we are currently running."

    FileDirectory allSubclasses do: [:class |
        class isActiveDirectoryClass ifTrue: [^ class]].


that loop answers UnixFileDirectory. This is because:

nixFileDirectory class >> isActiveDirectoryClass
    "Does this class claim to be that properly active subclass of FileDirectory for this platform?
    Default test is whether the primPathNameDelimiter matches the one for this class. Other tests are possible"

    ^self pathNameDelimiter = self primPathNameDelimiter

answers true.

But anyway, why MacFileDirectory class >> isActiveDirectoryClass  answers false?

If we see:

MacFileDirectory class >> isActiveDirectoryClass
    ^ super isActiveDirectoryClass
        and: [(Smalltalk getSystemAttribute: 1201) isNil
                or: [(Smalltalk getSystemAttribute: 1201) asNumber <= 31]]


(Smalltalk getSystemAttribute: 1201    ->   '255'


So.....my questions are:

1) Should it answer Unix one, or MacOS?  I guess than MacOS, and if it is unix, then we have to solve the kind of problem I have
2) Why (Smalltalk getSystemAttribute: 1201    ->   '255'
3) Why not using "Smalltalk platformName" to detect which FileDirectory to use??

Thanks

Mariano


Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory default is wrong in MacOS

Eliot Miranda-2


On Sun, Nov 21, 2010 at 3:44 PM, Mariano Martinez Peck <[hidden email]> wrote:
Hi. The simplest way to find the problem (if my case it was muuuch more than this), I found the following:  MacOS is case insensitive (I've just figure it out).

Actually no.  It can be either.  You can choose.  Mine is case-sensitive.

 
Since it is a UNIX at the end, I thought it was case sensitive, but it seems it is not. Now, suppose that in the directory where my image is, I have the file called 'zaraza'. If I evaluate this:

(FileDirectory default fileOrDirectoryExists: 'zaraza')  ->>>> true

I should get true. And the same with:


(FileDirectory default fileOrDirectoryExists: 'ZARAZA')  ->>>> false

But....I get false instead of true. Which is wrong in Mac OS.
The problem is that  FileDirectory default  -----> UnixFileDirectory

And this is because

FileDirectory class >> activeDirectoryClass
    "Return the concrete FileDirectory subclass for the platform on which we are currently running."

    FileDirectory allSubclasses do: [:class |
        class isActiveDirectoryClass ifTrue: [^ class]].


that loop answers UnixFileDirectory. This is because:

nixFileDirectory class >> isActiveDirectoryClass
    "Does this class claim to be that properly active subclass of FileDirectory for this platform?
    Default test is whether the primPathNameDelimiter matches the one for this class. Other tests are possible"

    ^self pathNameDelimiter = self primPathNameDelimiter

answers true.

But anyway, why MacFileDirectory class >> isActiveDirectoryClass  answers false?

If we see:

MacFileDirectory class >> isActiveDirectoryClass
    ^ super isActiveDirectoryClass
        and: [(Smalltalk getSystemAttribute: 1201) isNil
                or: [(Smalltalk getSystemAttribute: 1201) asNumber <= 31]]


(Smalltalk getSystemAttribute: 1201    ->   '255'


So.....my questions are:

1) Should it answer Unix one, or MacOS?  I guess than MacOS, and if it is unix, then we have to solve the kind of problem I have
2) Why (Smalltalk getSystemAttribute: 1201    ->   '255'
3) Why not using "Smalltalk platformName" to detect which FileDirectory to use??

Thanks

Mariano



Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory default is wrong in MacOS

Schwab,Wilhelm K
In reply to this post by Mariano Martinez Peck
Mariano,

Dumb question: what file system is in use?  I sometimes get surprised with case insensitivity on Linux when using shared media with Microsoft file systems.  From the looks of things, that is probably _not_ your problem, but it's worth ruling out.

Bill



Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory default is wrong in MacOS

Mariano Martinez Peck
H Bill. The file system (as much as I can notice) seems to be Mac OS Extended (Journaled). I am a completly mac newbie...so...

Eliot: WOW! I didn't know that you can choose....I am googling now how to change to case sensitive (I hope I don't need to reformat).

thanks

mariano

On Mon, Nov 22, 2010 at 12:55 AM, Schwab,Wilhelm K <[hidden email]> wrote:
Mariano,

Dumb question: what file system is in use?  I sometimes get surprised with case insensitivity on Linux when using shared media with Microsoft file systems.  From the looks of things, that is probably _not_ your problem, but it's worth ruling out.

Bill




Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory default is wrong in MacOS

Stéphane Ducasse
In reply to this post by Schwab,Wilhelm K

On Nov 22, 2010, at 12:59 AM, Mariano Martinez Peck wrote:

> H Bill. The file system (as much as I can notice) seems to be Mac OS Extended (Journaled). I am a completly mac newbie...so...
>
> Eliot: WOW! I didn't know that you can choose....I am googling now how to change to case sensitive (I hope I don't need to reformat).

you have but don't do that you may get a lot of trouble.
Imagine you send me two files which are case sensitive and my system may blow up or I lose something and I send it back to you
fucked up.

So if you are ready to not interact with other people change else keep it the way it is.

I got problem because damien in the past changed it and interacted with me.

>
> thanks
>
> mariano
>
> On Mon, Nov 22, 2010 at 12:55 AM, Schwab,Wilhelm K <[hidden email]> wrote:
> Mariano,
>
> Dumb question: what file system is in use?  I sometimes get surprised with case insensitivity on Linux when using shared media with Microsoft file systems.  From the looks of things, that is probably _not_ your problem, but it's worth ruling out.
>
> Bill
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory default is wrong in MacOS

Mariano Martinez Peck


On Mon, Nov 22, 2010 at 9:17 AM, Stéphane Ducasse <[hidden email]> wrote:

On Nov 22, 2010, at 12:59 AM, Mariano Martinez Peck wrote:

> H Bill. The file system (as much as I can notice) seems to be Mac OS Extended (Journaled). I am a completly mac newbie...so...
>
> Eliot: WOW! I didn't know that you can choose....I am googling now how to change to case sensitive (I hope I don't need to reformat).

you have but don't do that you may get a lot of trouble.
Imagine you send me two files which are case sensitive and my system may blow up or I lose something and I send it back to you
fucked up.

So if you are ready to not interact with other people change else keep it the way it is.

I got problem because damien in the past changed it and interacted with me.

Ok, thanks for the advice. But still, the problem with Pharo is present.

My OS is case insensitive, but FileDirectory default is working like case sensittive.....
 

>
> thanks
>
> mariano
>
> On Mon, Nov 22, 2010 at 12:55 AM, Schwab,Wilhelm K <[hidden email]> wrote:
> Mariano,
>
> Dumb question: what file system is in use?  I sometimes get surprised with case insensitivity on Linux when using shared media with Microsoft file systems.  From the looks of things, that is probably _not_ your problem, but it's worth ruling out.
>
> Bill
>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory default is wrong in MacOS

Stéphane Ducasse
In reply to this post by Stéphane Ducasse
>
> > H Bill. The file system (as much as I can notice) seems to be Mac OS Extended (Journaled). I am a completly mac newbie...so...
> >
> > Eliot: WOW! I didn't know that you can choose....I am googling now how to change to case sensitive (I hope I don't need to reformat).
>
> you have but don't do that you may get a lot of trouble.
> Imagine you send me two files which are case sensitive and my system may blow up or I lose something and I send it back to you
> fucked up.
>
> So if you are ready to not interact with other people change else keep it the way it is.
>
> I got problem because damien in the past changed it and interacted with me.
>
> Ok, thanks for the advice. But still, the problem with Pharo is present.
>
> My OS is case insensitive, but FileDirectory default is working like case sensittive.....


This means that the VM should give a way to know if the filesystem is key sensitive
without that we can only guess or we could have a test saving a file and checking.


Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory default is wrong in MacOS

Henrik Sperre Johansen

On Nov 22, 2010, at 12:58 08PM, Stéphane Ducasse wrote:

>>
>>> H Bill. The file system (as much as I can notice) seems to be Mac OS Extended (Journaled). I am a completly mac newbie...so...
>>>
>>> Eliot: WOW! I didn't know that you can choose....I am googling now how to change to case sensitive (I hope I don't need to reformat).
>>
>> you have but don't do that you may get a lot of trouble.
>> Imagine you send me two files which are case sensitive and my system may blow up or I lose something and I send it back to you
>> fucked up.
>>
>> So if you are ready to not interact with other people change else keep it the way it is.
>>
>> I got problem because damien in the past changed it and interacted with me.
>>
>> Ok, thanks for the advice. But still, the problem with Pharo is present.
>>
>> My OS is case insensitive, but FileDirectory default is working like case sensittive.....
>
>
> This means that the VM should give a way to know if the filesystem is key sensitive
> without that we can only guess or we could have a test saving a file and checking.
>
>

As a (fragile) hack, you could use isAFileNamed: with a known existing filename on the platform containing uppercase characters
i.e. the platform function called in FilePlugin>primitiveFileOpen (at least on Mac) respects the case-sensitivity setting.

Problem is when new version come out where the file is moved/removed, you're in trouble :)

Cheers,
Henry
Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory default is wrong in MacOS

Mariano Martinez Peck
In reply to this post by Stéphane Ducasse


On Mon, Nov 22, 2010 at 12:58 PM, Stéphane Ducasse <[hidden email]> wrote:
>
> > H Bill. The file system (as much as I can notice) seems to be Mac OS Extended (Journaled). I am a completly mac newbie...so...
> >
> > Eliot: WOW! I didn't know that you can choose....I am googling now how to change to case sensitive (I hope I don't need to reformat).
>
> you have but don't do that you may get a lot of trouble.
> Imagine you send me two files which are case sensitive and my system may blow up or I lose something and I send it back to you
> fucked up.
>
> So if you are ready to not interact with other people change else keep it the way it is.
>
> I got problem because damien in the past changed it and interacted with me.
>
> Ok, thanks for the advice. But still, the problem with Pharo is present.
>
> My OS is case insensitive, but FileDirectory default is working like case sensittive.....


This means that the VM should give a way to know if the filesystem is key sensitive
without that we can only guess or we could have a test saving a file and checking.


I thought about that. I was thinking to implement   MacFileDirectory >> isCaseSensitive
so that it keeps a class side variable with the boolean. The getter can be lazy, and in nil, you can write a dummy file, and check.
But even if you do this, we still have a problem, becuase right now FileDirectory default is answering the unix one....and unix is always case-sensitive, so we shouldn't change that.  So first we need to modify so that we can use the MacFileDirectory, and then how to modify it so that it can support both case sensitive, and insensitive.


 

Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory default is wrong in MacOS

Mariano Martinez Peck
In reply to this post by Henrik Sperre Johansen


On Mon, Nov 22, 2010 at 1:16 PM, Henrik Johansen <[hidden email]> wrote:

On Nov 22, 2010, at 12:58 08PM, Stéphane Ducasse wrote:

>>
>>> H Bill. The file system (as much as I can notice) seems to be Mac OS Extended (Journaled). I am a completly mac newbie...so...
>>>
>>> Eliot: WOW! I didn't know that you can choose....I am googling now how to change to case sensitive (I hope I don't need to reformat).
>>
>> you have but don't do that you may get a lot of trouble.
>> Imagine you send me two files which are case sensitive and my system may blow up or I lose something and I send it back to you
>> fucked up.
>>
>> So if you are ready to not interact with other people change else keep it the way it is.
>>
>> I got problem because damien in the past changed it and interacted with me.
>>
>> Ok, thanks for the advice. But still, the problem with Pharo is present.
>>
>> My OS is case insensitive, but FileDirectory default is working like case sensittive.....
>
>
> This means that the VM should give a way to know if the filesystem is key sensitive
> without that we can only guess or we could have a test saving a file and checking.
>
>

As a (fragile) hack, you could use isAFileNamed: with a known existing filename on the platform containing uppercase characters
i.e. the platform function called in FilePlugin>primitiveFileOpen (at least on Mac) respects the case-sensitivity setting.


Thanks Henry for the workarround. It works.

 
Problem is when new version come out where the file is moved/removed, you're in trouble :)

Cheers,
Henry

Reply | Threaded
Open this post in threaded view
|

Re: FileDirectory default is wrong in MacOS

johnmci
Likely a bit of history is needed here. 

The original file logic for macintosh OS 7.5.5 worked with HFS, later I guess it was 8.x Apple introduced HFS+ which allowed for files names to be longer
than N where N was mmm 26 or 32? That would be the check for 255 characters.  So we had to deal with pre HFS and post HFS+ systems. 

Later when os-x came out I had to rewrite the file lookup logic to properly handle symbolic links and os-9 aliases, then earlier in the last decade it became 
apparent that Apple was moving the developer community from using OS-7.x.x file naming conventions to unix naming convention. So again some nasty bit of logic to help the image and the VM sort between is it HFS, HFS+, pre os-x names, or post os-x names (255 chars & case insensitive). 

In all this Apple decided to go with case insensitive file names, but on the os-x server case sensitive.  Now of course you can switch but that sometimes leads to interesting problems. 

So one is that you can have four volumes mounted, each of which has different case sensitivity, so it's not the operating system that drives case or no, it's the volume.  When I looked at this 10 years back it was *difficult* to drag the information about the volume out of the OS, now it's easier, but mounting NFS  etc perhaps makes things a bit fuzzy again.  

However this issue is a problem because you can't do   "FileSystem isCaseSensitive"   it's more like  "FileSystem isCaseSensitiveForVolume: volume"  
Clouding that is of course the fact what is a volume across different OS? and of course in unix you can have mount points so it's unclear how you know...

Anyway as you see a bit of restructuring would need to be done because you have to consider each file path differently. 


On 2010-11-22, at 6:11 AM, Mariano Martinez Peck wrote:


Problem is when new version come out where the file is moved/removed, you're in trouble :)

Cheers,
Henry


--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================