file name case sensitivity

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

file name case sensitivity

Eliot Miranda-2
Hi All,

    being a control freak I always enable case sensitivity on my Macs.  The Mac OS X file system has optional case sensitivity, insensitive by default.  I once got burned with a check-out where one directory overwrite another and chose sensitivity from then on.  This has caused a few problems over the years, including a Flash update that failed.  No matter.

Squeak has FileDirectory class>>isCaseSensitive answer a hard-coded boolean.  Not good.  I see this from stackoverflow:

"Keep in mind that you might have multiple file systems with different casing rules. For example, the root filesystem could be case-sensitive, but you can have a case-insensitive filesystem (e.g. an USB stick with a FAT filesystem on it) mounted somewhere. So if you do such checks, make sure that you make them in the directory that you are going to access.

Also, what if the user copies the data from say a case-sensitive to a case-insensitive file system? If you have files that differ only by case, one of them will overwrite the other, causing data loss. When copying in the other direction, you might also run into problems, for example, if file A contains a reference to file "b", but the file is actually named "B". This works on the original case-insensitive file system, but not on the case-sensitive system.

Thus I would suggest that you avoid depending on whether the file system is case-sensitive or not if you can. Do not generate file names that differ only by case, use the standard file picker dialogs, be prepared that the case might change, etc."

Luckily this is only tested in a couple of places.  Most of the time the system resolves names by going through primDirectoryEntryFor: which leaves it up to the individual file system to decide (and hence get the answer right).

I wonder what does FileSystem do about this?
--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: file name case sensitivity

Nicolas Cellier



2014-05-11 19:12 GMT+02:00 Eliot Miranda <[hidden email]>:
Hi All,

    being a control freak I always enable case sensitivity on my Macs.  The Mac OS X file system has optional case sensitivity, insensitive by default.  I once got burned with a check-out where one directory overwrite another and chose sensitivity from then on.  This has caused a few problems over the years, including a Flash update that failed.  No matter.

Squeak has FileDirectory class>>isCaseSensitive answer a hard-coded boolean.  Not good.  I see this from stackoverflow:

"Keep in mind that you might have multiple file systems with different casing rules. For example, the root filesystem could be case-sensitive, but you can have a case-insensitive filesystem (e.g. an USB stick with a FAT filesystem on it) mounted somewhere. So if you do such checks, make sure that you make them in the directory that you are going to access.

Also, what if the user copies the data from say a case-sensitive to a case-insensitive file system? If you have files that differ only by case, one of them will overwrite the other, causing data loss. When copying in the other direction, you might also run into problems, for example, if file A contains a reference to file "b", but the file is actually named "B". This works on the original case-insensitive file system, but not on the case-sensitive system.

Thus I would suggest that you avoid depending on whether the file system is case-sensitive or not if you can. Do not generate file names that differ only by case, use the standard file picker dialogs, be prepared that the case might change, etc."

Luckily this is only tested in a couple of places.  Most of the time the system resolves names by going through primDirectoryEntryFor: which leaves it up to the individual file system to decide (and hence get the answer right).

I wonder what does FileSystem do about this?
--
best,
Eliot


Not better it seems... It's hardcoded too.

UnixStore class>>isCaseSensitive
    "except for OSX the default is case sensitive"
    ^ Smalltalk os isMacOSX not

Though, it's only used in one place in Pharo 3.0: ExternalDropHandler to test file extension matching (matchesExtension:).



Reply | Threaded
Open this post in threaded view
|

Re: file name case sensitivity

timrowledge
Case sensitivity is one of those things that needs to be checked at usage time. You can’t always rely upon a file name being proper for the runtime scenario just because it is ok when you build the system. For example - the big obvious one is the directory separator and we’ve all run into places where some twerp has built a filename string on a Windows box and it is now being passed into a prim on an OS X machine. Boom.

A long time ago -  sufficiently long that I can’t even really work out what keywords to search my email database for - we had a long discussion on the problems of file systems and how inherently unreliable naming and status checking and permissions checking  are. I do recall some really scary problems that people had actually come across over the years.

The real answer is that we should have got away from stupid files keyed by dumb strings decades ago but… well that’s life.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Fac ut vivas. = Get a life.



Reply | Threaded
Open this post in threaded view
|

Re: file name case sensitivity

Chris Muller-3
On Wed, May 14, 2014 at 4:23 PM, tim Rowledge <[hidden email]> wrote:
> Case sensitivity is one of those things that needs to be checked at usage time. You can’t always rely upon a file name being proper for the runtime scenario just because it is ok when you build the system. For example - the big obvious one is the directory separator and we’ve all run into places where some twerp has built a filename string on a Windows box and it is now being passed into a prim on an OS X machine. Boom.

Yes, when we have object representations for these things, there's no
reason to use Strings, ever.  The first-class FileDirectory and
DirectoryEntry's are portable.

> A long time ago -  sufficiently long that I can’t even really work out what keywords to search my email database for - we had a long discussion on the problems of file systems and how inherently unreliable naming and status checking and permissions checking  are. I do recall some really scary problems that people had actually come across over the years.
>
> The real answer is that we should have got away from stupid files keyed by dumb strings decades ago but… well that’s life.

It's so ingrained into me, it's hard to even imagine an alternative
that doesn't.

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Fac ut vivas. = Get a life.
>
>
>