PDA

View Full Version : Case-sensitive file system option in Mac OS X Panther 7B21.


MacBytes
Aug 3, 2003, 07:56 PM
Category: Mac OS X
Link: Case-sensitive file system option in Mac OS X Panther 7B21. (http://www.hardmac.com/niouzcontenu.php?date=2003-08-03#328)

Posted on MacBytes.com (http://www.macbytes.com)

Nermal
Aug 3, 2003, 08:01 PM
What would you want this for? I can't think of a single reason why you'd want your filesystem to be case sensitive, although I'm sure I'll know hundreds of reasons by the time you've all finished explaining it to me :)

arn
Aug 3, 2003, 08:09 PM
can anyone verify this (that the option is there)?

the reason you want it is because most unix systems are case-sensitive. It can cause problems when you have a directory of files from a case sensitive format coming to a system wtih a case-insensitive format.

arn

MrMacMan
Aug 3, 2003, 08:23 PM
Originally posted by arn
can anyone verify this (that the option is there)?

the reason you want it is because most unix systems are case-sensitive. It can cause problems when you have a directory of files from a case sensitive format coming to a system wtih a case-insensitive format.

arn

Yup, and I want more then one 'My Folder' on my desktop.

I also want 'my Folder' & 'my folder' which currently is not allowed.

arn
Aug 3, 2003, 08:29 PM
yep, this has been verified to be true. Case-sensitive format available in recent Panther build. Not available in Jaguar. Uncertain if this was available in the first Panther build.

[yes, Jaguar did have UFS which is case sensitive]

MrMacMan
Aug 3, 2003, 08:37 PM
Originally posted by arn
yep, this has been verified to be true. Case-sensitive format available in recent Panther build. Not available in Jaguar. Uncertain if this was available in the first Panther build.

Even I could have told you that...

Hmmm the first build? Drat... not using that build...

cbrantly
Aug 3, 2003, 08:39 PM
I don't know a lot about this, but I do know that you can't run the BSD package manager on OS X b/c it requires a case-sensitive file system. I guess this would allow that.

Powerbook G5
Aug 3, 2003, 08:39 PM
So does anyone know if this will be the default on the actual shipping version of Pather preinstalled or will you have to format and reinstall to obtain this function on new computers with Panther?

DeusOmnis
Aug 3, 2003, 08:43 PM
It would be cool to make it default. I hope it is.... I dont like having any inferiorities on my computer, and this is one.

mymemory
Aug 3, 2003, 08:43 PM
This is gonna make my life little more closer to hell!!! now we have to be sure if our log/pass was "mymemory" or "MyMemory" or "Mymemory".

I'm glad I worked with unix systems about 5 years ago and I was allways carefull about that, actually I felt paranoic about it but well, OSX wasn't build to make our life easier any way.

Some day I'm gonna have a lot of money and I'm gonna buy the rights of OS 9.2.2. and make 9.5 just for me:rolleyes:

dermeister
Aug 3, 2003, 08:52 PM
OK, this is a VERY bad idea for a consumer OS. I'll go ******** insane.

jaedreth
Aug 3, 2003, 09:02 PM
It's not the default value.

You have to *format* the partition for case sensitive/journelling HFS+.

It's an option, and a very good one for unix geeks to have, that way they can migrate from one 'nix to another.

Jaedreth

Booga
Aug 3, 2003, 09:04 PM
While I think case-insensitive and preserving is vastly better than case-sensitive, I do see that it's nice to have the option. I could see many universities replacing UNIX clusters with MacOS X G5's, now that you can essentially do everything with MacOS X you can do with UNIX.

Unfortunately UNIX picked case sensitive, probably because it takes less processing power and UNIX was written for the old PDP machines decades ago. And at this point, there are still some packages that actually depend on this functionality.

Oh well, as long as it remains a non-default option I'm ok with it.

Pedro Estarque
Aug 3, 2003, 09:05 PM
Originally posted by mymemory
Some day I'm gonna have a lot of money and I'm gonna buy the rights of OS 9.2.2. and make 9.5 just for me:rolleyes: [/B]
count me in! "9.5, the same old interface you love, plus protected memory, preemptive multitasking..."
Sort of Copland's return

bobindashadows
Aug 3, 2003, 09:06 PM
Originally posted by jaedreth
It's not the default value.

You have to *format* the partition for case sensitive/journelling HFS+.

It's an option, and a very good one for unix geeks to have, that way they can migrate from one 'nix to another.

Jaedreth
Yep, as long as they keep it *not* default, that's good. It will drive people ******** insane, and I hope Apple sticks on the path of user-friendliness. It's just easier and more intuitive to not have "BobJones" and "bobjones" be different. Remember, kids and old people use these machines. Kids and old people!

Powerbook G5
Aug 3, 2003, 09:08 PM
I wonder if you can select case sensitive as a default for a BTO option. Wouldn't that help to be able to just check an option on the Apple store and have it automatically case sensitive or not when it is shipped to you instead of having to reformat and partition your drive and reinstall the OS just to get the feature? It seems like a promising feature, but I'd like to have it set up for me when I get it shipped instead of having to deal with redoing my system just to activate it after the fact.

Roller
Aug 3, 2003, 09:10 PM
Originally posted by bobindashadows
Yep, as long as they keep it *not* default, that's good. It will drive people ******** insane, and I hope Apple sticks on the path of user-friendliness. It's just easier and more intuitive to not have "BobJones" and "bobjones" be different. Remember, kids and old people use these machines. Kids and old people!

I agree about not making it the default. Also, am I correct in assuming that this doesn't apply to file extensions? That would really be messy.

BaghdadBob
Aug 3, 2003, 09:10 PM
Case Sensetive/Journaled?

Anyone care to comment on the "journaled" aspect or is this something normal I'm mistaking for something else?

Aciddan
Aug 3, 2003, 09:16 PM
Originally posted by arn
yep, this has been verified to be true. Case-sensitive format available in recent Panther build. Not available in Jaguar. Uncertain if this was available in the first Panther build.

Case sensitivity is available in Jaguar, though you need to format your drive as a "Unix Drive". Instead of Macintosh HD, your HD is called "/".

I just created 2 files on My HD under Jaguar: Newfile.txt and NeWfile.txt -> seperate and distinct.

I guess the real guts of this information is not that it's case sensitive, but rather it's a HFS+ volume that is sensitive.

-- Dan :D

bennetsaysargh
Aug 3, 2003, 09:19 PM
this should be an option in the system prefs because some people want it, and other people won't know what to do with themselves. that is the oly way they can do it.

EelBait
Aug 3, 2003, 09:22 PM
Originally posted by dermeister
OK, this is a VERY bad idea for a consumer OS. I'll go ******** insane.

I doubt if your already tenuous grasp on reality is taken into consideration when debating adding worthwhile and requested features to their OS.

OS X has had the option of formatting a partion using UFS since the early days, but no systems ship that way, nor is it the default option. A case-sensitive file system make sense (no pun intended) when working with legecy Unix programs expecting there to be one, especially from a security angle. Remember all the noise about the security hole created in Apache because of the case-insensitivity of HFS+? Apple had to add in a special mod to keep apache from giving up information is wasn't supposed to. For certain types of applications, it would be easier to use a case-sensitive file system, than to have to retrofit a zillion additional checks just to work on OS X.

When I refer to applications, I'm not referring to your average click-and-drool stuff found daily on VersionTracker, but special-purpose vertical applications that would run in a data center. (Think Xserve.)

If Apple wants to attract more Unix software developers, they need to provide features to support them. Not just die-hard OS9 lusers who choose to see no further than their own diminishing world.

MadCabbit
Aug 3, 2003, 09:24 PM
Panther still has UFS, but the new case-sensitivity is a feature added into hfs. if you format it as such, Disk Utility will only see it as Journaled, and can't tell if its case-sensitive (even immediately after a format), but it DOES work. However you can NOT install on a partition formatted like this (at least as of 7B21), it forces you to reformat as just HFS+, HFS+ (journaled), or UFS.

I hope by the time Panther is released, that it will let you install on a partition formatted this way. I'm looking forward to putting down my $129 for this, I can't wait. :)

alandail
Aug 3, 2003, 09:26 PM
This will improve unix compatibility. You have to reformat old drives to enable it, but I'd expect new machines to ship with this turned on.

I don't understand why people think it'd drive them insane? Exactly where is the downside? You open a file, save it, close it, the name stays the same.

The only people who it should even impact at all is programmers who will have to fix the case on their include files.

omnivector
Aug 3, 2003, 09:27 PM
for the person who asked a journaled file system creates a "mini database" of information about the file system for faster file system checks and better reliability for recovering lost data due to power failure or a system failure.<br><br>
i saw the case sensitive option when i installed the panther beta 2, i just hope they give us jaguar people an option to upgrade an hfs+ file system to hfs+ case sensitive without formatting.

EelBait
Aug 3, 2003, 09:29 PM
Originally posted by BaghdadBob
Case Sensetive/Journaled?

Anyone care to comment on the "journaled" aspect or is this something normal I'm mistaking for something else?

The journaled file system is already there in Jaguar if you want to use it. On OS X Server, activating it consists of a checkbox in the DiskUtility. On OS X (regular) it's available merely by issuing a command:


% sudo diskutil enableJournal /


(diskutil is the command-line equivalent of the DiskUtility)

d00d
Aug 3, 2003, 09:29 PM
Originally posted by Pedro Estarque
count me in! "9.5, the same old interface you love, plus protected memory, preemptive multitasking..."
Sort of Copland's return Yeah, because it's just that easy... :rolleyes:

Cmon people. It's not as simple as adding a single line of code (System.useProtectedMemory(now)). It's really complicated and Apple had extreme amounts of trouble accomplishing it. What makes you think that a company that could have profited from doing such a change can't do it, but some guy with barely enough money to buy the rights to the old OS can? Get a grip. OS 9 is GONE and with good reason.

Powerbook G5
Aug 3, 2003, 09:30 PM
I hope you aren't calling me a loser for using OS 9...I don't see how OS 9 relates to case in/sensitivity, anyway.

Nermal
Aug 3, 2003, 09:31 PM
OK now that I know what it's for, you can have my viewpoint:

I think using a case-sensitive filesystem will break a lot of existing applications. I've got no idea how many programmers follow the case when writing apps, but I'm sure a great deal of them will just write filenames in whatever case they feel like, rather than checking to see the actual case of the filename. Did that make sense?

For this reason, I'm expecting that the case-sensitive option will be just that, an option. You can't install on a case-sensitive partition at the moment, and they might have to keep it that way for the reason above. However, I am sure that whatever they end up doing, it'll work well, cause it's Apple :)

Edit: Looks like alandail thought about the programmers before me. If only I could type faster!

simX
Aug 3, 2003, 09:34 PM
Originally posted by d00d
Yeah, because it's just that easy... :rolleyes:

Cmon people. It's not as simple as adding a single line of code (System.useProtectedMemory(now)). It's really complicated and Apple had extreme amounts of trouble accomplishing it. What makes you think that a company that could have profited from doing such a change can't do it, but some guy with barely enough money to buy the rights to the old OS can? Get a grip. OS 9 is GONE and with good reason.

Agreed. The next time I hear someone say something good about Copland, I'll scream.

Nermal
Aug 3, 2003, 09:39 PM
Originally posted by simX
Agreed. The next time I hear someone say something good about Copland, I'll scream.

Copland is excellent.

--- scream here :D ---

Seriously I've got no idea what Copland is, don't bother explaining it cause we're off topic enough as it is, but I'm sure we're gonna hear more anyway...

johnnowak
Aug 3, 2003, 09:42 PM
Thank god... no more having to do case-sensitive find/replace searches on C code to port case-sensitivity reliant software.

In a word... kickass.

NuVector
Aug 3, 2003, 10:02 PM
This is a good thing. It means that panther will be able to support high end Unix implementations such as AFS (Andrew File System) (http://archive.ncsa.uiuc.edu/General/CC/filesystems/afs/afs.html) without having to format the drive as UFS which isn't an optimal choice for Mac OS X and Classic.

What this means is that Apple is serious about bringing the best of the Unix world to Mac OS X implementations.

ralphh
Aug 3, 2003, 10:24 PM
When searcing the hard drive by file title, I assume Panther will offer a "Case-Sensitive" checkbox, correct?

And how are lists alphabetized? The "A...Z,a...z" ASCII/Unix thing you get with the ls command in Terminal is not desirable in Panther. Most users would probably prefer "A,a...Z,z".

alandail
Aug 3, 2003, 10:34 PM
Originally posted by ralphh
When searcing the hard drive by file title, I assume Panther will offer a "Case-Sensitive" checkbox, correct?

And how are lists alphabetized? The "A...Z,a...z" ASCII/Unix thing you get with the ls command in Terminal is not desirable in Panther. Most users would probably prefer "A,a...Z,z".

I'm sure pather will be smart about sorting - MacOS 9 is already smart about numbers. For instance - a file that starts

9-

will sort before a similar file that starts

10-

when a simple ascii sort would put 10 before 9.

Also - you can already confirm this - HFS+ isn't currently case sensitive, but it does retain case, so it's already having to deal with case when sorting file names. And you can see it sorts like this

a File
Another file
yet another file

zimv20
Aug 3, 2003, 10:36 PM
to me, a filesystem that equates 'A' with 'a' is as non-sensical as having 'A' equate with '#'.

i fully support the move to case-sensitivity.

AidenShaw
Aug 3, 2003, 10:37 PM
Case sensitivity is one of the most brain-damaged ideas to come from UNIX (IMHO) - case-preserving is much more human-friendly....

Maybe, someday, UNIX will add a case-preserving option and the rest of the world can stop the LCD appeasement tweaks.

Pedro Estarque
Aug 3, 2003, 10:45 PM
Originally posted by d00d
Yeah, because it's just that easy... :rolleyes:

Cmon people. It's not as simple as adding a single line of code (System.useProtectedMemory(now)). It's really complicated and Apple had extreme amounts of trouble accomplishing it. What makes you think that a company that could have profited from doing such a change can't do it, but some guy with barely enough money to buy the rights to the old OS can? Get a grip. OS 9 is GONE and with good reason.

Have you ever heard about humor sarcasm?
just to let you know, I'm running jaguar on a PM 7300. And I guess when you go through the trouble of running an OS on a system which is way bellow minimum configuration, its because you must like it some how.
That doesn't mean Copland couldn't have been better. Apple was lazy to develop a new OS and decided to go for UNIX. The advantage is that we now have all those free opensouce apps plus all the realiability that you would expect.
The disadvantage is that an average user, even if its the only one using the machine, has to deal with permissions.
OSX added huge complexity to the system, which could have been avoided if it was written from the ground up.

mvc
Aug 3, 2003, 10:48 PM
Originally posted by EelBait
I doubt if your already tenuous grasp on reality is taken into consideration when debating adding worthwhile and requested features to their OS.Not just die-hard OS9 lusers who choose to see no further than their own diminishing world.

I really think there is enough inane MS/Linux/OSX specific bigotry out in the forums without making a needless attack at someone who perhaps is more comfortable with "non technical" earlier versions of our own OS! God forbid we should now begin to perpetuate the attitudes of the elitist priesthoods of traditional IT just because we are running the OS on servers instead of flower-power iMacs.

We use Mac's partly because they are meant to be friendly, and so are we!;)

alandail
Aug 3, 2003, 10:58 PM
I still don't understand why anyone would have a problem with case sensitve file system. As I said in my first post, it improves compatibility and I fail to see where it causes a problem.

You open a file, edit it, and save it, and it keeps it's name. You don't end up with two files with different cases.

You take the file and email it to someone, email will retain the case, the other machine will retain the case, it'll come back with the same case.

The only time a user should ever care about the case of a file in a case sensitive file system is if you try to save one file to overwrite an existing file - and even then, you don't want to type the filename anyway because you have to worry about not only case, but also typos, you just want to click on the file you're replacing in the save dialog - something pather supports.

Other than that, it's a way to help bring more unix/linux software to the mac at the expense of programmers having to be more careful in typing their include statements.

It's a heck of a lot easier to go from case insensitive to case sensitive than to go the other way. And anything to help move more software to the Mac is utimately good for users.

bobindashadows
Aug 3, 2003, 11:08 PM
Originally posted by zimv20
to me, a filesystem that equates 'A' with 'a' is as non-sensical as having 'A' equate with '#'.

i fully support the move to case-sensitivity.
Man, I completely respect you, but that was the worst analogy ever. If you honestly believe that, then your logic is messed up somewhere. I mean... if you took out one of the horizontal lines in the # symbol, then it might kinda look like an A. more like a /-/. An H, rather. But seriously - it makes sense to equate A to a. They are the same letters of the alphabet. In english, we say "ehhhh" (fonzie style), to pronounce "A" in such situations as "Aim". If we are confronted with a lowercase "a", such as in "pay" or "way", we pronounce them "ehhhh" (fonzie style). However, when we see #, we english speakers do not pronounce it as "ehhhh" (again, fonzie style). We say either "number sign" for the less technical, or "pound". Depending on the situation, we may call it "shebang" (when accompanied with a !. We will never, ever, pronounce it "ehhh" like fonzie does.

This is why it makes sense to associate "A" with "a". I understand they are not the same character. They don't have the same ascii values. Whoop-dee-freakin-doo. You're using a system partly targeted at kids, adults who don't want a hassling computer, and the elderly. Do they have strong opinions on near-irrelevant topics such as case-sensitivity? Mostly, no. I say mostly because I'm a kid and I'm sitting here talking for way too long.

It will increase compatibility. That's great. People who need it can create partitions for it with Panther. That's great. The thing is, it's intuitive to have a file with one name represent just that file. If you were sitting in a desk job, and looked on your desk and say "TPS Report #1354896" and "TPS REPORT #1354896", would you think you are supposed to fill them out differently? Would you think that they are different, and needed to be treated as such? I know I wouldn't.

If you guys haven't read the article on the spatial finder at arstechnica, it's a good read, even though they hate macs there. (Not enough to talk about the PPC 970 and the finder, but they don't like them.)

If you are just using hyperbole... you have to support it. Unsupported hyperbole eliminates your authority, and can lead to length posts describing why you have faults in your logic.

asim
Aug 3, 2003, 11:10 PM
hopefully when saving a file that has an identical name (except for case) it will give a warning asking if you really want to do it...

that way, if you have a file called:

book report final.doc

and then revise it and try saving it as:

book report FINAL.doc

it will ask if you really want to do that since there may be some confusion. this way, if you tell someone "hey, 'print book report final' " they will be less likely to open the wrong one. granted, i think everyone should use version numbers, so you can say "print 'book report v2.4' " instead

alandail
Aug 3, 2003, 11:14 PM
Originally posted by Pedro Estarque
That doesn't mean Copland couldn't have been better. Apple was lazy to develop a new OS and decided to go for UNIX. The advantage is that we now have all those free opensouce apps plus all the realiability that you would expect.
The disadvantage is that an average user, even if its the only one using the machine, has to deal with permissions.
OSX added huge complexity to the system, which could have been avoided if it was written from the ground up.

Apple wasn't lazy - the Copland project almost did Apple in. They had to scrap it because it had bloated to the point where nobody even knew what the end product was supposed to be. I went to what I think was the 3rd annual copeland world wide developers conference - that's not the real name, but that's what I called it because they kept having these yearly developers conferences for an OS that wasn't shipping and had no ship date. You'd go from session to session and one team had no idea what the other team was doing - even when their tasks overlapped.

Throw the whole thing in the trash and start over was the only choice Apple had. They spent all of these resources on copeland and taligent, and had nothing to show for it and the shipping MacOS was suffering.

The result is they bought NeXT and eventually Steve Jobs took over. Had that not happened, and they instead kept throwing money at Copeland, there would be no Apple today.

The Unix part of OSX is a huge advantage for Apple. But it's only one advantage, other people has unix. The other huge advantage is Cocoa. With Cocoa, I built tool in an hour last night that would have taken me days to do in any other OS. And the Cocoa version was a lot more functional than what I could have gotten using any other OS. I've been a Mac developer since 1984 and Cocoa is the best thing they ever had.

How long has OS X been out? I've been using it for my OS since before v1.0 and I can't remember the last time I had to worry about file permissions. And the permissions in the OS are no different than what copeland have had to have if it were going to be a multi-user/server OS.

arn
Aug 3, 2003, 11:17 PM
Originally posted by alandail
I still don't understand why anyone would have a problem with case sensitve file system. As I said in my first post, it improves compatibility and I fail to see where it causes a problem.

I think the problem people have with it is that in our day to day lives.... we do not treat things as case-sensitive.

In conversation - Bob, bob and boB are irrelevant. It's all the same.

Anyhow - might I remind everyone to take it easy. This is not being forced on anyone. It's an option. If you don't want it, it doesn't affect you. It's been an option since Mac OS X 10.0. (under UFS). If it didn't affect you then, it doesn't affect you now.

arn

mvc
Aug 3, 2003, 11:17 PM
Originally posted by Pedro Estarque
Apple was lazy to develop a new OS and decided to go for UNIX. The advantage is that we now have all those free opensouce apps plus all the realiability that you would expect.
The disadvantage is that an average user, even if its the only one using the machine, has to deal with permissions.
OSX added huge complexity to the system, which could have been avoided if it was written from the ground up.

I agree, it's been a mixed blessing from the average users point of view, but I think Apple have done a clever job of producing a layered response to this issue. OSX can be as smart as you want it to be, and increasingly meets the needs of both command line powerusers and the point and click mainstream.

I believe we have the best of both worlds, and it should only get better. This case sensitive option is just another way Apple can match the OS to the wider environment without prejudicing mainstream acceptance and ease of use.

Under OS9, we were in danger of becoming completely irrelevant to multiple markets simultaneously! There was nowhere left to go with that OS - it was a well polished efficient solution within its limits, but it was an island.

Now we are seeing growth in markets we could never have had a moments credibility in before, all largely because of the Unix connection. If we had written from the ground up, none of that flow on would have happened - it would have just been another elegant boutique OS - think Beos!

solvs
Aug 3, 2003, 11:22 PM
Originally posted by AidenShaw
Case sensitivity is one of the most brain-damaged ideas to come from UNIX (IMHO) - case-preserving is much more human-friendly....

Maybe, someday, UNIX will add a case-preserving option and the rest of the world can stop the LCD appeasement tweaks.
Read my lips people: OPTION. This is an option. If you need or want it. If you don't, don't use it. Very simple. It doesn't even seem to be the default.

Some of us may actually find this useful.

Nermal
Aug 3, 2003, 11:24 PM
Originally posted by asim
hopefully when saving a file that has an identical name (except for case) it will give a warning asking if you really want to do it...

that way, if you have a file called:

book report final.doc

and then revise it and try saving it as:

book report FINAL.doc

it will ask if you really want to do that since there may be some confusion. this way, if you tell someone "hey, 'print book report final' " they will be less likely to open the wrong one. granted, i think everyone should use version numbers, so you can say "print 'book report v2.4' " instead

This is a good idea. A prompt will help avoid confusion, and prevent you from accidentally saving a file under two different names. As to using version numbers, that's just weird :p

mvc
Aug 3, 2003, 11:31 PM
Originally posted by asim
i think everyone should use version numbers, so you can say "print 'book report v2.4' " instead

Now thats the sort of idea that a Terminator might approve of. Why don't we get rid of peoples names as well, there are so many duplicates out there!:p

alandail
Aug 3, 2003, 11:45 PM
Originally posted by arn
I think the problem people have with it is that in our day to day lives.... we do not treat things as case-sensitive.

In conversation - Bob, bob and boB are irrelevant. It's all the same.



Other than saving a file with a new name, when do you actually type the name of a file? You double click to open a file, you edit it, you save it. At no point do you type it's name. It's only when you save a file for the first time or with a different name that you actually type the name.

And if you're trying to replace a file, pather now lets you just click on the file you're replacing - again no typing.

So when is a typical user ever going to notice this option is even on?

alandail
Aug 3, 2003, 11:48 PM
Originally posted by asim
that way, if you have a file called:

book report final.doc

and then revise it and try saving it as:

book report FINAL.doc



Who even works that way - you revise it and save it - you don't type the file name again?

I do agree that a warning if you saved another file using an existing name that is different only by case could be helpful. But again clicking on the file you want to replace makes more sense becasue it also eliminates the issue of typos.

cb911
Aug 3, 2003, 11:59 PM
sounds good. it's always good to have more options, and after people use it for a while they might find it useful.

i guess it's pretty much guaranteed that this will be in the final release of Panther?

Booga
Aug 4, 2003, 12:02 AM
Originally posted by NuVector
This is a good thing. It means that panther will be able to support high end Unix implementations such as AFS (Andrew File System) (http://archive.ncsa.uiuc.edu/General/CC/filesystems/afs/afs.html) without having to format the drive as UFS which isn't an optimal choice for Mac OS X and Classic.

What this means is that Apple is serious about bringing the best of the Unix world to Mac OS X implementations.

I agree with the 2nd paragraph, but the first one makes no sense. AFS is its own file system, as far as the kernel is concerned. I believe that there is already an AFS implementation for MacOS X, which I think suffers the same problem as the NeXT one did-- that is, the OS loves to stat lots of directories, which in the case of AFS means pinging tens of thousands of machines around the planet. HFS+ supporting case-sensitivity should have no bearing on AFS's implementation on MacOS X that I can see.

Powerbook G5
Aug 4, 2003, 12:04 AM
I just hope that Panther will be out before too long, I'd love to get a new PowerBook with Panther preinstalled, but if not, I'd be first in line to get a copy--from all that I have read, this looks like the most promising version of any OS yet put out by Apple. I know a lot of people are wondering why they'd pay to upgrade again, but this case sensitive HFS+ just adds yet another new feature to an already great wealth of new or improved features to further enhance the user experience. Whether you choose to use this feature or not, it's definitely a good thing to step up to new features whenever possible.

x-virge
Aug 4, 2003, 12:14 AM
Originally posted by Booga
I agree with the 2nd paragraph, but the first one makes no sense. AFS is its own file system, as far as the kernel is concerned. I believe that there is already an AFS implementation for MacOS X, which I think suffers the same problem as the NeXT one did-- that is, the OS loves to stat lots of directories, which in the case of AFS means pinging tens of thousands of machines around the planet. HFS+ supporting case-sensitivity should have no bearing on AFS's implementation on MacOS X that I can see.

I'm fairly certain that the original poster meant that now Mac OS X can *serve* AFS without having to use UFS. As in, be a place where you store files for others to access via AFS. AFS is case-sensitive, so I'd imagine the underlying filesystem on an AFS server would have to be case sensitive too.

ultrafiel
Aug 4, 2003, 12:22 AM
Originally posted by alandail
Other than saving a file with a new name, when do you actually type the name of a file? You double click to open a file, you edit it, you save it. At no point do you type it's name. It's only when you save a file for the first time or with a different name that you actually type the name.

And if you're trying to replace a file, pather now lets you just click on the file you're replacing - again no typing.

So when is a typical user ever going to notice this option is even on?

Actually I use "save as..." quite a bit at work. We do Photoshop work, and keep multiple versions of every file we do (original, final, tiff, jpg, etc.) But who really cares, because like it has been said, it is an option. Oh, and I'm stuck in OS 9 at work, so I don't even want to go there, because at home I haven't even had classic installed for over a year (which I recommend, because on machines that I do use with classic on them sometimes funny things happen).

cnladd
Aug 4, 2003, 12:50 AM
Originally posted by Nermal
This is a good idea. A prompt will help avoid confusion, and prevent you from accidentally saving a file under two different names. As to using version numbers, that's just weird :p

Version numbers were a beautiful thing on the VMS filesystem. See, versioning was actually built in to the filesystem itself. Let's say the directory listing shows it as "MERGER DOCUMENT;9". Referencing it as "MERGER DOCUMENT" will bring up the most recent version (version 9). However, you can always call up "MERGER DOCUMENT;3" to bring up the version from six saves ago.

It was out of the way (by default, you always used the latest), but you could still access previous versions. Used a bit more disk space, but the number of versions kept was configurable (and you could purge previous versions.)

I know it'll never be implemented again in any commercial OS, but it was a beautiful thing to work with.

cnladd
Aug 4, 2003, 12:54 AM
Originally posted by AidenShaw
Case sensitivity is one of the most brain-damaged ideas to come from UNIX (IMHO) - case-preserving is much more human-friendly....

Maybe, someday, UNIX will add a case-preserving option and the rest of the world can stop the LCD appeasement tweaks.

UNIX has nothing to do with being human-friendly. It was invented by programmers, for programmers. More importantly, by and for C programmers (where 'A' and 'a' are two completely different things.)

Case sensitivity is not "brain damaged" idea, but it can be very valuable to programmers. For most of those coming from the UNIX side of the fence, this is great that Apple's implementing it.

Finally, why would you care about this so much? It's an option. You're not being forced to use it. You're not even being asked to use it. The people who love case sensitivity will love this. The ones who hate it... will never even see it.

zimv20
Aug 4, 2003, 01:02 AM
Originally posted by bobindashadows
Man, I completely respect you, but that was the worst analogy ever. If you honestly believe that, then your logic is messed up somewhere. I mean... if you took out one of the horizontal lines in the # symbol, then it might kinda look like an A. more like a /-/. An H, rather.


omg -- can you please get a pair of binoculars and look straight up? off in the distance you'll see my point, waaaaaayyy above your head!!!

# is the musical sharp symbol. i was comparing the A major chord (A), the A minor chord (a) and the A# major chord (#).

;)

i am very much kidding (especially about the binocs). my point was indeed about the ascii character set, from the OS' perspective. i.e. the association of 'A' and 'a' is a human phenomenon. i've been using unix for about 20 years now and case insensitivity makes no sense to me. after all -- why lose information when you don't have to?

cnladd
Aug 4, 2003, 01:04 AM
Originally posted by BaghdadBob
Case Sensetive/Journaled?

Anyone care to comment on the "journaled" aspect or is this something normal I'm mistaking for something else?

A journaled filesystem is like a database transaction log. When the system is going to make a change to the disk, it first records its intent in the journal. The change is then made by the system, after which the journal entry is removed.

The theory is that the disk can crash at any time. If a normal filesystem crashes in an "unclean" state, it can take a long time to do a consistency check. With a journaled filesystem, the system goes through the journal and "replays" it.

Basically, it goes through it "line by line" and either finishes the changes that were started or takes the date and rolls it back to the state it was at before. It all depends on where things were at when the crash occured.

In the end, it makes it easier for a filesystem to remain consistent through a crash and, if there is a crash, makes recovery faster: just replay the small log instead of checking every inch of data.

Sorry for the overly long explanation, folks.

zimv20
Aug 4, 2003, 01:09 AM
here's an example of what's wrong w/ osx right now (that will be fixed w/ this change). go to the command line and type:

% touch foo Foo


in unix, i'd expect two files to be created. but on osx, i only get "foo". and there's no error message.

% ls
Applications/ Movies/ TheFindByContentFolder/
Desktop/ Music/ TheVolumeSettingsFolder/
Desktop Folder/ Network Trash Folder/ bin/
Documents/ Pictures/ devel/
F@H1/ Public/ foo
F@H2/ Send Registration@
Library/ Sites/


but if you do this:

% ls -l foo Foo


you get the _very_ unexpected:

-rw-r--r-- 1 steve staff 0 Aug 4 00:57 Foo
-rw-r--r-- 1 steve staff 0 Aug 4 00:57 foo


wtf? are there two of them now? no, they're the same file (check inode):

% ls -il foo Foo
2666360 -rw-r--r-- 1 steve staff 0 Aug 4 00:57 Foo
2666360 -rw-r--r-- 1 steve staff 0 Aug 4 00:57 foo


and then, if you:

% rm Foo

it deletes both of them. THAT'S a problem, 'cuz to the average user it looks like two different files.

edit: added inode numbers

gotohamish
Aug 4, 2003, 01:52 AM
Originally posted by bobindashadows
It will drive people ******** insane...

Actually, it will probably '******** insane people's drives!'

Snowy_River
Aug 4, 2003, 02:50 AM
Originally posted by alandail
Who even works that way - you revise it and save it - you don't type the file name again?

I do agree that a warning if you saved another file using an existing name that is different only by case could be helpful. But again clicking on the file you want to replace makes more sense becasue it also eliminates the issue of typos.

I work with applications that, when opening an old file (made with an old version of the software) modifies the name to signify that it's being updated to the newer format. However, when I save, I generally want to save back to the original name, and often find it easier to simply retype the name than to try to edit out the name change...

Snowy_River
Aug 4, 2003, 02:51 AM
Originally posted by alandail
...and even then, you don't want to type the filename anyway because you have to worry about not only case, but also typos, you just want to click on the file you're replacing in the save dialog - something pather supports.


Oh, praises be to Apple! This is one of my most longed for features for the save dialogs! They've finally listened!!!

Foocha
Aug 4, 2003, 04:10 AM
Windows file system NTFS is case sensitive, but Window Explorer (equivalent to Finder) is case insensitive - this is arguably the best of both worlds - easy for average users and developers. It's actually about time that Apple sorted this problem out. It is possible for Apple to make the Finder case insensitive even if the file system underneath still respects case.

As a Web developer, this is going to make my life a whole lot easier. All our Web servers are Linux and as such case sensitive. However, our development server is Mac OS X, as is my desktop machine. As such, it is not possible to test effectively how a site will work on the live server.

Whilst Mac OS X is UFS compatible, many of the Mac apps I use, including Classic, are not, so using UFS is not an option. Also, I bet Mac OS X on UFS has not be as thoroughly tested by Apple, and so is less reliable.

grahamtriggs
Aug 4, 2003, 05:18 AM
Originally posted by EelBait
A case-sensitive file system make sense (no pun intended) when working with legecy Unix programs expecting there to be one, especially from a security angle. Remember all the noise about the security hole created in Apache because of the case-insensitivity of HFS+? Apple had to add in a special mod to keep apache from giving up information is wasn't supposed to. For certain types of applications, it would be easier to use a case-sensitive file system, than to have to retrofit a zillion additional checks just to work on OS X.

But it doesn't make sense when working with Mac programs, which might try to load the same file referencing it with multiple casings (or at least a different one to how it exists) on disk - so they'll all be broken unless the developer issues a patch.

As mentioned elsewhere, references in include files may be broken - so they may need to be fixed before a developer can issue a patch!

Security hole in Apache? That runs on Windows - and that happens to be case-insensitive too...

Whilst I can understand that there may be some Unix-originating software that may be a pain to deal with because it is expecting case-sensitivity, can someone please explain what makes case-sensitivity in an OS/file system a good thing?

IMHO, allowing two files of the same name - that only differ in case - is a fundamentally bad thing... it is confusing to know what they are for. Anyone that thinks you save the file - it keeps that name - no problem is missing the point. Take a simple example - you create document, save it as 'Hello'... sometime later, you create another document, save it as 'hello' - no warning, as they are 'different' names... then one day you want to load the first file - you remember you used the word 'hello' for the filename, and there are a load of files in directory, so you just type in 'hello' and - it's a different file...

IMHO, case-sensitivity is a *legacy* artefact, caused either by programmers too lazy to implement case-insensitivity, or so concerned about performance that they can't afford the handful of clock-cycles (and memory?) case-insensitivity would take - something that is more or less irrelevant nowadays...

Whilst I can see that in the current situation, case-sensitivity may prove useful to some, it certainly shouldn't be the default for MacOS X - and quite frankly it is something that Unix should have migrated from years ago... This is one of the major reasons why Unix does not have a larger user base - because they are slow/reluctant to move from something that 'works' to something that the majority find 'usable'...

Apple][Forever
Aug 4, 2003, 05:37 AM
I PERSONALLY futzed my BSD subsystem by compiling and installing something that accidentally overwrote files (in, I believe, /bin) which caused a lot of Applescript command line GUI tools to crash horribly. Took me a while to figure out, too, since I assumed HFS+ was case-sensitive.

So, yeah, I like this option.

MasonMcD
Aug 4, 2003, 06:47 AM
Aside from all these ramblings on case-sensitivity, did anyone notice the mysql and Apache2 preference panes? Where the heck are those?

Rincewind42
Aug 4, 2003, 07:19 AM
Originally posted by alandail
This will improve unix compatibility. You have to reformat old drives to enable it, but I'd expect new machines to ship with this turned on.

I would expect new machines to come with this OFF by default.

I don't understand why people think it'd drive them insane? Exactly where is the downside? You open a file, save it, close it, the name stays the same.

True, but there are more complex usage patterns than that. For example, what happens when a user links a picture of some sort, which on their HD is called "Turbine.jpg" and they they decide that they want to start over. They figure that instead of relinking the image they'll just replace it with a new one. In their rush to finish the project they save their new file as "turbine.jpg". They check back and can't for the life of them figure out why their new image isn't showing up. They go look in their images folder and suddenly notice that there are two "turbine.jpg" files (from their POV, from the computer's POV there is "Turbine.jpg" and "turbine.jpg", of course).

Said user relinks the file, mildly frustrated. And then goes to print the file. Guess what? Error, file not found. The user again screams out wondering why this is happening.

It turns out that when the program goes to print it does an upcase on the entire string because the printer module is ancient and doesn't support case-insensitive compares. And no one wants to touch the code in their because, well, it's ancient and it works (and it took them 3 months to get it working on MacOS X so they intend to let it stick around until it dies).

Now said user is ready to put a hole through his computer.

The only people who it should even impact at all is programmers who will have to fix the case on their include files.

More like all the programmers who now have to revise their code for untested assumptions. How many programs out there just plain don't work on UFS formatted volumes? Multiply that now by case-sensitive HFS and who knows how many more won't work. Heck, from what I've read on this thread, I can already name a big one that doesn't work on case-sensitive HFS - the OS Installer =p.

I still don't understand why anyone would have a problem with case sensitve file system. As I said in my first post, it improves compatibility and I fail to see where it causes a problem.

The problem is in the user part of the equation. Most users are not savvy enough to realize that README.TXT and Readme.txt can be two different files! How much background do most users have to assert that this can be true? Nearly nothing in real life is case sensitive. Sure, we have case rules for writing, but the meaning of the words are identical in most instances regardless of the case used (Names are pretty much the only words that can be misinterpreted due to case issues, and even then not many of them).

YOU explain to grandma that she has to double click on "My Great Program" and not "my great program" to launch the program. And you can do that Now in 10.2. Just turn on Hide File Extensions in the Finder. Imagine telling grandma to open the folder "Vacation Pictures" when there are 4 variants of it in your pictures folder.

You open a file, edit it, and save it, and it keeps it's name. You don't end up with two files with different cases.

In the simplest usage case, yes. In more complex usage cases... maybe...

You take the file and email it to someone, email will retain the case, the other machine will retain the case, it'll come back with the same case.

The fact that e-mail may or may not preserve case is orthogonal to this issue. And I can easily see an issue with this -- Sender calls the file Foo.txt, Reciever already has a file called foo.txt where they save the attachment. Now reciever has to figure out which file is the one they just saved...

The only time a user should ever care about the case of a file in a case sensitive file system is if you try to save one file to overwrite an existing file - and even then, you don't want to type the filename anyway because you have to worry about not only case, but also typos, you just want to click on the file you're replacing in the save dialog - something pather supports.

Users rarely worry about typos in filenames (because they are easily corrected) and personally I feel that when you want to replace a file you should have that extra safety net of having to type out the entire name (or at least do something extra to get the same name). That, and the functionality isn't universal (at least, not yet...)

Other than that, it's a way to help bring more unix/linux software to the mac at the expense of programmers having to be more careful in typing their include statements.

It's a heck of a lot easier to go from case insensitive to case sensitive than to go the other way. And anything to help move more software to the Mac is utimately good for users.

Never underestimate the assumptions of programmers. If you've lived on a case-insensitive file system for your enttire career there are probably a lot of things you do to "normalize" file names that you wouldn't otherwise realize without being on a case-sensitive file system. And who knows how user files will respond to this change. I wonder how many old Desktop Publishing and Office files are sitting around linked to files that the user has changed the case of after the fact. How many will just print their old garage sale flyer by telling the Finder to print their file and walking away. 10 minutes later they come back to 50 copies of their flyer with the wrong picture on it.

It's not just about include files. This really will affect far more people than just programmers. And just because it may make some programs easier to port doesn't mean that programmers like it. Case sensitivity in file names is just as much a bad assumption in programming as case insensitivity. But no one has to time to program for every case, so they program for the common one.

edit: formatting, forgot a couple things.

ktlx
Aug 4, 2003, 07:23 AM
Originally posted by cnladd
UNIX has nothing to do with being human-friendly. It was invented by programmers, for programmers. More importantly, by and for C programmers (where 'A' and 'a' are two completely different things.)

That is not true. UNIX was developed by researchers for technical writers. That is why the basic text processing in UNIX is so strong.

Rincewind42
Aug 4, 2003, 07:34 AM
Originally posted by zimv20
here's an example of what's wrong w/ osx right now (that will be fixed w/ this change). go to the command line and type:

% touch foo Foo


in unix, i'd expect two files to be created. but on osx, i only get "foo". and there's no error message.

% ls
Applications/ Movies/ TheFindByContentFolder/
Desktop/ Music/ TheVolumeSettingsFolder/
Desktop Folder/ Network Trash Folder/ bin/
Documents/ Pictures/ devel/
F@H1/ Public/ foo
F@H2/ Send Registration@
Library/ Sites/


but if you do this:

% ls -l foo Foo


you get the _very_ unexpected:

-rw-r--r-- 1 steve staff 0 Aug 4 00:57 Foo
-rw-r--r-- 1 steve staff 0 Aug 4 00:57 foo


wtf? are there two of them now? no, they're the same file (check inode):

% ls -il foo Foo
2666360 -rw-r--r-- 1 steve staff 0 Aug 4 00:57 Foo
2666360 -rw-r--r-- 1 steve staff 0 Aug 4 00:57 foo


and then, if you:

% rm Foo

it deletes both of them. THAT'S a problem, 'cuz to the average user it looks like two different files.


To the average user this all looks like gibbarish. To the average UNIX user it may look like two different file names (how many Linux users are running on a case-insensitive file system so that they can still access those files when they are running their other operating system?).

You try walking your sister (or brother, or uncle, or whoever in your family is not tech savvy) through a bunch of command line instructions over the phone because of something stupid like the fact that user folders are references by paths in MacOS X and the little one of the house managed to rename her home folder. Just don't do it while others are watching or they may wonder why your saying things like "Lady Snake" (ls) or "Execute Xavier In Tailand" (exit) and call the Unamerican Activi... uh.. Department of Homeland Defense office on you :D.

Samir 3.0
Aug 4, 2003, 08:23 AM
can anyone verify this (that the option is there)?

Uncertain if this was available in the first Panther build.

It was present from the first build, the developer preview, you had just to open the disk utility from the boot cd and select it but even if my iBook is updated with the 7A202 doesn't seem to work.

This OS growing better every day and now the performances look very similar from those that i had with mac os 9 but with much more stability and usability

Jon the Heretic
Aug 4, 2003, 08:32 AM
Apple has totally lost touch with its consumers, "the rest of us". They need to hire real human factors professionals, like they used to have when they were creating the classic MacUI. Today's Apple is twixt graphic artists and die hard engineers, neither of whom have a clue about what most users need. Artists know how to make things pretty, and engineers know to make things work. That is their skill areas and I have no doubt Apple hires best of breed in both areas. But "case sensitivity"? What a frickin' dinosaur. It is yet another concession to the engineers within Apple who don't care or understand usability.

The bottomline of a OS has to be the end users. Apple USED to excel in this area. MacOS X has rock solid stability but the interface is, uh, "troubled" (nicest word I could find without starting a flame war). Apple no longer has people in its employ who understand end users; without systematic end user testing and user-centered design, you can expect at best improvements to the UI in dribs and drabs, irratically deployed at seemingly random intervals. You can also expect sacrifices to usability like elimination of metadata, relative pathnames and now --- god help us --- case insensitivity. Obviously, the only end user community Apple cares about is developers, who care primarily about porting code written for less sophisticated systems (that is, ones that don't understand metadata or relative pathnames or which treat letters as though they don't already have pyschologically valid equivalencies.)

Boy, is Grandma ***screwed***.

grahamtriggs
Aug 4, 2003, 08:37 AM
Originally posted by alandail
The only time a user should ever care about the case of a file in a case sensitive file system is if you try to save one file to overwrite an existing file - and even then, you don't want to type the filename anyway because you have to worry about not only case, but also typos, you just want to click on the file you're replacing in the save dialog - something pather supports.

Fine if you want to overwrite an existing file - but what if you *don't* want to overwrite an existing file? ie. You type in a name, and it accepts it as there is nothing with the same name and case in the folder - you then have two different files with the 'same' name... And no, users don't check to see if there is a file with that name there - they just type it in, and wait for the warning if the file already exists...

Other than that, it's a way to help bring more unix/linux software to the mac at the expense of programmers having to be more careful in typing their include statements.

I'm all for more software on the Mac, and I'm all for giving more reasons for the Unix community to adopt MacOS X... but a lot of this software won't be of benefit to many existing Mac users - the interface won't be right...

It's a heck of a lot easier to go from case insensitive to case sensitive than to go the other way. And anything to help move more software to the Mac is utimately good for users.

Says who? I would *never* intentionally choose to use the same name differing only case for two files... for me, going from sensitive to insensitive is a non-issue... the other way round is just constant headaches...

grahamtriggs
Aug 4, 2003, 08:43 AM
Originally posted by Jon the Heretic
Apple has totally lost touch with its consumers, "the rest of us". They need to hire real human factors professionals, like they used to have when they were creating the classic MacUI. Today's Apple is twixt graphic artists and die hard engineers, neither of whom have a clue about what most users need. Artists know how to make things pretty, and engineers know to make things work. That is their skill areas and I have no doubt Apple hires best of breed in both areas. But "case sensitivity"? What a frickin' dinosaur. It is yet another concession to the engineers within Apple who don't care or understand usability.

I certainly wouldn't choose case sensitivity, but I don't really see it as a problem if they incorporate it as an *option* for those that want it... the only problem would be if they made it the default...

The bottomline of a OS has to be the end users. Apple USED to excel in this area. MacOS X has rock solid stability but the interface is, uh, "troubled" (nicest word I could find without starting a flame war). Apple no longer has people in its employ who understand end users; without systematic end user testing and user-centered design, you can expect at best improvements to the UI in dribs and drabs, irratically deployed at seemingly random intervals. You can also expect sacrifices to usability like elimination of metadata, relative pathnames and now --- god help us --- case insensitivity. Obviously, the only end user community Apple cares about is developers, who care primarily about porting code written for less sophisticated systems (that is, ones that don't understand metadata or relative pathnames or which treat letters as though they don't already have pyschologically valid equivalencies.)

Have you used Panther? The improvement in usability is quite staggering...

omnivector
Aug 4, 2003, 08:44 AM
Originally posted by Jon the Heretic
Apple has totally lost touch with its consumers, "the rest of us". They need to hire real human factors professionals, like they used to have when they were creating the classic MacUI. Today's Apple is twixt graphic artists and die hard engineers, neither of whom have a clue about what most users need. Artists know how to make things pretty, and engineers know to make things work. That is their skill areas and I have no doubt Apple hires best of breed in both areas. But "case sensitivity"? What a frickin' dinosaur. It is yet another concession to the engineers within Apple who don't care or understand usability.

The bottomline of a OS has to be the end users. Apple USED to excel in this area. MacOS X has rock solid stability but the interface is, uh, "troubled" (nicest word I could find without starting a flame war). Apple no longer has people in its employ who understand end users; without systematic end user testing and user-centered design, you can expect at best improvements to the UI in dribs and drabs, irratically deployed at seemingly random intervals. You can also expect sacrifices to usability like elimination of metadata, relative pathnames and now --- god help us --- case insensitivity. Obviously, the only end user community Apple cares about is developers, who care primarily about porting code written for less sophisticated systems (that is, ones that don't understand metadata or relative pathnames or which treat letters as though they don't already have pyschologically valid equivalencies.)

Boy, is Grandma ***screwed***.

No offense but you're quite mistaken. I'm one of those Linux -> Mac OS X switchers, and I've done my fair share of programming. Many of the developers like myself that they switch over will start writing mac software (like myself). I've rarely seen people switch from mac to windows, but when it happens it's usually because Macs are lacking in the software arena.

aptenergy
Aug 4, 2003, 08:48 AM
Originally posted by Jon the Heretic

Boy, is Grandma ***screwed***. [/B]

Dude, lighten up. It's a freaking option.

That said, let me ask a question: Has anyone with file journaling in Panther found it a detriment to their disk performance? I remember when journaling first came out that reports said overall data retrieval and that sort would go down by like 20% or so. Is the speed drop in Panther not as noticeable?

Pedro Estarque
Aug 4, 2003, 08:57 AM
Originally posted by mvc
it would have just been another elegant boutique OS - think Beos!
Sometimes I still wonder what would have happened if apple had bought BE. It was probably the most amazing OS experience I've ever had. At the time I was using MacOS 8, where even a click-n-hold of the mouse would stop the entire system. Then I installed BEOS and I could drag a window without stopping the animations running on it. Even running from a Zip-100 it was the fastest GUI OS I've ever used.
It was not a server system, but it was not a boutique OS as well.
Today I've learned to love the terminal, and all this UNIX world was a trilling experience for me. But I'm not an average user, I like to dig in to the system.
Maybe in time Apple can hide all this UNIX features from the home user, but keep them available for the ones who need them. And I think 10.3 is in this track

stompy
Aug 4, 2003, 09:05 AM
For an excellend discussion as I've encountered on case insensitivity vs. case sensitivity, see

http://www.birdhouse.org/macos/beos_osx/redux.html

by Scot Hacker, letter by Brian Tiemann

Apple's way makes sense

I received a ton of email in defense of Apple's approach to case-sensitivity (HFS+ is case-respecting but case insensitive). And you know what? I'm convinced. I've changed my tune. Apple's way makes sense. I think my initial reaction was simply one of surprise. It felt strange to use a Unix shell but not to have full case sensitivity. It felt like something was unfinished. But after reading the many (lengthy) diatribes I received on this issue, I've come around. Here's the letter that expressed Apple's position most cogently -- the one that changed my mind:

As for the "rightness" of using a case-preserving, case-insensitive filesystem, though... well, I come from a UNIX-geek background myself, and it was many galling years before I understood why it was designed that way in the first place.

Case-sensitivity seems like a great idea to UNIX-heads. These are people who want every possible command and workflow to have a distinct, deterministic result -- the kind of thinking you expect from an academic/research environment. Synonymous workflows that arrive at the same result are anathema to science. Students filling up directories with lab data like for there to be a difference between "a.dat" and "A.dat" and sorts them according to ASCII value rather than orthography. It's a sure-footed, obedient scheme, one where the computer does exactly what the user wants it to do -- because the user is one who has the expertise to issue instructions that are very clear and precise and speak the same internal language that the computer does.

But that's not who desktop OSes are written for. In a desktop OS, there is no conceivable reason why you would want to have two files in the same folder that are, for all intents and purposes, named the same thing. "Picture1.jpg" is the same thing as "picture1.jpg". No, really -- it is. It's the metaphor by which you organize the people in your address book. Would you consider "john thomas" to be a different person from "John Thomas"? Would you be unconfused by a set of introductions at a party with both these fellows in attendance?

Mac and Windows users have to have filenames read to them over the phone by support techs. They have to be able to write little sticky notes to their mothers about how to open up the mail program, without worrying about how the filenames are capitalized. Haven't you ever fumed over a URL with initial-caps in the folder names in the path, having to fiddle with capitalization until you get a response that's anything but a 404? Haven't you ever been secretly pleased that e-mail addresses aren't case-sensitive?

(Side note: Apache's mod_speling module corrects capitalization errors, but does it the "right" way-- issuing a redirect so the browser re-requests the file with the correct capitalization, thus closing the loop as a "case-preserving" scheme. Windows servers just happily serve up the file with the wrong capitalization, leading the client to save a file capitalized differently from the copy on the server.)

Bear in mind that it's MUCH more work for a filesystem to be case-insensitive than -sensitive. A filesystem is case-sensitive by default, in the simplest case; it can only be made case-INsensitive through a lot of extra engineering. In UNIX, all the system has to do is sort on the ASCII values of the first letters of the filenames. In the Mac OS and Windows, the filesystem has to be smart enough to create synonyms of various letters -- A for a, and so on -- and sort accordingly. That takes a LOT of code. It's a testament to the completeness of the original Mac OS that in 1984 this was all handled properly, before Windows even brought lower-case letters to the PC side.

It goes well beyond that, too. Look at how the Mac handles foreign, extended characters. Rather than the Windows way, in which you have to pick accented characters from a bizarre grid of upper-ASCII values, the Mac builds such things into the keyboard input routines in a way that's workflow-consistent. Press Option+U, and you get an umlaut. Then enter a vowel, and the umlaut combines with the vowel. Option+U,U -- and there's your .

And what about sorting? The Mac sorts right along with the other U variants. iTunes recognizes Bjork and Bjrk as the same artist. There's a completeness to the thinking here that Windows still only approximates. Windows sorts all of your folders first in a folder listing, before any files. Why is that? And it still has that infuriating and inexplicable stupidity of not allowing you to create a file with a name that's an all-caps acronym, without helpfully converting it to an initial-caps string for you.

It's taken me a long time to come to terms with the appropriateness of a case-preserving, case-insensitive filesystem, but I've done it. It's clear to me now that while it's nice in an academic sense to have deterministic control over filenames to the point where two files that differ only in capitalization can exist in the same folder, it's simply nothing but confusing to a casual user for there to be a distinction. It's an area in which Mac OS X inherits some of the very hard and complete work of the classic Mac OS development in the form of the HFS+ filesystem, but in which some of the recent UI decisions are causing ease-of-use to suffer (for instance, hidden filename extensions, which lead to the never-before-seen problem of multiple files with the same APPARENT filename in the same folder -- we can only hope we don't end up like Windows, with six files in a folder all called "setup"). And this is one case where I hope Apple develops with the home user in mind, rather than the academic UNIX geek.

It's telling that over the past several years, in attempts to reassure myself of the usefulness of case-sensitivity, I've asked UNIX geek after UNIX geek to name a single truly compelling reason for it to exist. And to a man, not one of them could think of anything more concrete than "Well... y'know... it's just better."

No, the Mac way of handling lexicography is by far the most intensive and complete out there. Certainly by comparison to UNIX and Windows. And I've come to appreciate it as a true Mac advantage.

-- Brian Tiemann

Powerbook G5
Aug 4, 2003, 09:22 AM
I just don't understand why so many people are so violantly again Apple giving people to use a case sensitive HFS+ as an *option*. Does everyone know the meaning of option? It's not on by default! The average "children and grandmas" who use MacOS X won't even know that it's there! When they buy a new iMac, it will not be case sensitive because you have to format and then repartition it *for* case sensitivity. I'm sorry if this has already been pointed out, but halfway through the replies I just got tired of so many people being so blindly against a nicely added and needed feature to OS X that quite a few people have needed for so long. If you don't like it, then fine, don't use it. You have to basically go out of your way to use this feature, anyway, so it's not like it's going to make Panther a zillion times more complicated when you suddenly upgrade to 10.3.

iPC
Aug 4, 2003, 09:26 AM
Originally posted by bobindashadows
Yep, as long as they keep it *not* default, that's good. It will drive people ******** insane, and I hope Apple sticks on the path of user-friendliness. It's just easier and more intuitive to not have "BobJones" and "bobjones" be different. Remember, kids and old people use these machines. Kids and old people!
Ummm.... I don't know about you, but my brain does not see this:

bobjones = BobJones

Yet another example of Apple following M$ lead.... (Microsoft did this for win2k - logins and such now case sensitive) j/k ;)

Apple does get dissed for making their system (OS and apps) dumbed down to the lowest common denominator. This will help to alleviate that. If Apple wants to claim UNIX style, then implement it.....

Pedro Estarque
Aug 4, 2003, 10:48 AM
Originally posted by stompy
For an excellend discussion as I've encountered on case insensitivity vs. case sensitivity, see

http://www.birdhouse.org/macos/beos_osx/redux.html

by Scot Hacker, letter by Brian Tiemann

Nice article

ryaxnb
Aug 4, 2003, 10:48 AM
Originally posted by dermeister
OK, this is a VERY bad idea for a consumer OS.
Yes, for quite a few people it would probably be a little annoying. But if that's the case, Apple probably won't make it the default option and thus people not "in the know" don't have to worry. (After all average users don't reformat their hard drive, much less use advanced formatting options).

bignumbers
Aug 4, 2003, 10:49 AM
Mistake. I can see some benefit for case-sensitivity, mainly to allow some unix apps to run right. Problem is, it would confuse average users and many existing Mac apps would break.

At first thought I was glad it would be an "option". But then we'd end up with yet another file system (HFS+, UFS, and now csHFS+ or whatever). I can see it now, "Sorry, this application requires another file system. Please reformat your drive." And of course there would be competing requirements, so you'd probably need different partitions for different apps.

A better solution is to allow unix apps to run in a case-sensitive "shell" of some sort (I have no problem with Terminal and so-forth being case-sensitive). Still that would be problematic.

Chances are the carbon/cocoa API's will "autotranslate" like they do with path separators (: and /) but that's already causing problems.

Bottom line it adds convenience for a small number of users at the hardship of a larger number. (But since it's in Panther, it's probably here to stay whether I like it or not!)

What I WOULD like added is a feature from my VAX/VMS days - version numbers. A full VMS filename was "abcdefg.hijkl;37". The version number was updated automatically, and one could specify (various ways) how many versions to keep around. In code, if you didn't specify a version number the OS just returned the most recent version. Made going back to an old version of files a breeze.

ryaxnb
Aug 4, 2003, 10:57 AM
Originally posted by Roller
Also, am I correct in assuming that this doesn't apply to file extensions? That would really be messy.
I'm afraid it would apply to file extensions. In Jaguar (which I have) the case-sensitive UFS file system does. It considers Mail.app and Mail.apP, etc. to be different.

ryaxnb
Aug 4, 2003, 11:06 AM
OS 9 can use preemptive multitasking and multithreading (though not protected memory) as far as I know. It involves having applications use the "Thread Manager" and stuff, but almost no OS 9 apps have preemptive multitasking/multithreading support.

ryaxnb
Aug 4, 2003, 11:10 AM
Originally posted by Nermal
Seriously I've got no idea what Copland is
Copland is one of Apple's old attempts (pre-OS 8) to make a more advanced OS, with protected memory, better multitasking and other stuff, but it didn't work out.

modyouup
Aug 4, 2003, 11:13 AM
What a pain in the ass! **** case sensitivity!

ryaxnb
Aug 4, 2003, 11:15 AM
Originally posted by mvc
I really think there is enough inane MS/Linux/OSX specific bigotry out in the forums without making a needless attack at someone who perhaps is more comfortable with "non technical" earlier versions of our own OS!
Yeah, personally I use X, but OS 9 has its advantages, especially for users of older machines.

chomsky
Aug 4, 2003, 11:24 AM
Since it is clear that case sensitivity in HFS+ will be an option and not the default, it is curious that so many would rail so loudly against it.

The user base of MacOS is changing, and I think there are quite a few people who are afraid of that. The flood of tech-savvy Unix people into the fold has begun.

This is revitalizing Apple.. it should be embraced, not feared and reviled. Yes, perhaps in the days to come Mac users will no longer be synonymous with 'technically-challenged'. This will enrich, not dilute, the Mac community.

According to the slogans, it's a good thing to 'think different'. Well, we Unix people do. We think that B and b are different characters, and aren't thrown into mental disarray by the presence of more than one mouse button. We like to know more exactly what our computers are doing, so that we may control them better and make them serve our needs.

Please don't complain every time a concession is made for Apple's Unix folk. We're here to stay, so let's make friends...

c. thomas (another unix switcher)

ryaxnb
Aug 4, 2003, 11:30 AM
Originally posted by Jon the Heretic
You can also expect sacrifices to usability like elimination of metadata, relative pathnames and now --- god help us --- case insensitivity.
They don't eliminate those! OS X still supports metadata, though they're trying to get rid of it; OS X supports relative pathnames; and OS X will probably have case insensitvity as the default option, so end users don't notice any difference.

edenwaith
Aug 4, 2003, 11:44 AM
Well, damn, I never noticed too much. If asked yesterday if OS X was case-sensitive or not, I would have assumed it was. But I guess that is a good feature to be case-sensitive, like most other *nix operating systems. Better to go from insensitive to sensitive. The other way could mess quite a few things up with a system, otherwise.

alandail
Aug 4, 2003, 11:49 AM
what elimination of metadata? Are you talking about the resource fork? That's still supported, as is the far more powerful and compatible concept of a package.

And what elimination of relative paths. Unix most definately supports relative paths.

And I still don't understand the complaints on here. case insinsitivity is an obstical to adoption of OSX. I'm not talking about as a home PC, I'm talking about enterprise. Without case sensitivity, Apple has a Unix that isn't compatible with any other unix. You can't just replace any other unix box with a Mac (or a rack of XServes) because some software doesn't work right when you do. So that alone eliminates Macs from consideration because potential enterprise customers aren't going to rewite all of that software to run on a case insenstive file system. They would, however, recompile on a compatible unix that offered better price/performance.

cnladd
Aug 4, 2003, 12:17 PM
Originally posted by alandail
what elimination of metadata? Are you talking about the resource fork? That's still supported, as is the far more powerful and compatible concept of a package.


I know a lot of folks (Windows and UNIX types) haven't liked resource forks, but I've always thought it was a rather neat concept!

As for packages, those will be around for a long time, I think. It's one of the features that Apple brought over from NEXTSTEP that I really loved. I get stoked every time I get to show my coworkers that this one little file they see in the Finder is really a full-blown directory, complete with everything that application needs -- and it's all hidden away from the user. They see the app as a single file. Both the Windows folks and the more traditional UNIX folks around here just think that's the coolest thing.

And you can't beat its user friendliness.

Rincewind42
Aug 4, 2003, 01:02 PM
Originally posted by ryaxnb
OS 9 can use preemptive multitasking and multithreading (though not protected memory) as far as I know. It involves having applications use the "Thread Manager" and stuff, but almost no OS 9 apps have preemptive multitasking/multithreading support.

Actually, preemptive threads came from Multiprocessing Services and any application that supported multiple CPUs used preemptive threads (mostly a few highpowered professional apps like Photoshop)

Originally posted by chomsky
Since it is clear that case sensitivity in HFS+ will be an option and not the default, it is curious that so many would rail so loudly against it.

I don't think that all of us are ragging on case sensitivity per-se, but the notion that it should be the default, or is the correct way of doing things. For 99% of the uses out there it is not the right way to do things, and likely it will not be supported by any non-command line applications either because aside from Java programmers (and probably not them either), anyone writing a GUI program on Mac OS X is assuming a case-insensitive file system.

I can definately see anyone who isn't trying to run a particular package that requires it (and truthfully, I can't see why a particular package _should_ require case sensitive file names to run -- sounds like the programmers assuming too much about their users) as preferring tradiational HFS+.

And if the only issue is compiling someone else's application, then I think that it is the original author's fault for not using consistent case in the file name. And anyone who is using case-sensitivity to differentiate two different include/source files is just setting themselves up for a world of hurt =).

chomsky
Aug 4, 2003, 02:01 PM
I don't think I've ever heard more bitching and moaning about the addition of an optional feature.

"Hey, they're adding an optional feature that creates compatibility with Unix! Grrr! Curse those uppity Unix geeks, we don't need them! If Apple had only been given a few more decades, they would've finished Copland, and we would have shown them all! Waahh!!"

Please, give it a rest.

daveL
Aug 4, 2003, 02:21 PM
Originally posted by mymemory
This is gonna make my life little more closer to hell!!! now we have to be sure if our log/pass was "mymemory" or "MyMemory" or "Mymemory".

I'm glad I worked with unix systems about 5 years ago and I was allways carefull about that, actually I felt paranoic about it but well, OSX wasn't build to make our life easier any way.

Some day I'm gonna have a lot of money and I'm gonna buy the rights of OS 9.2.2. and make 9.5 just for me:rolleyes:
What does file system case sensitivity have to do with login ids and passwords?

BTW, case insensitive login ids and passwords would always be easier to crack than case sensitive ones.

tjwett
Aug 4, 2003, 07:58 PM
i understand what all the fuss is about. if you don't want to use it, just turn it off. it's obvious this is an OPTIONAL feature that was added for people who really need it/want it, serious Unix personnel. i'll probably never enable this feature myself, but it's nice to it's there if i ever need it. this reminds me of people who complain about violence or profanity on the t.v. or radio. the solution is easy, change the channel! we should be psyched Apple is paying attention to power users and the Unix community. this also means that more and more people are finally considering the Mac as a viable server solution. give them the Unix features they are used to i say. just an ot observation, there has been a serious surge of OS X Server/Unix admin jobs here in NYC in recent months.

cnladd
Aug 4, 2003, 08:28 PM
Originally posted by tjwett
this reminds me of people who complain about violence or profanity on the t.v. or radio. the solution is easy, change the channel!

But we can't have our children exposed to mindless, senseless, depraved acts of case sensitivity!

You can't just change the channel on a filesystem, you... you... you monster!

jettredmont
Aug 4, 2003, 08:28 PM
Originally posted by Foocha
Windows file system NTFS is case sensitive, but Window Explorer (equivalent to Finder) is case insensitive - this is arguably the best of both worlds - easy for average users and developers.


Huh?

I believe you are quite mistaken there. I have NTFS running under Windows 2000 and Windows XP, and it's definitely not case sensitive at the DOS prompt. In fact, it's not case sensitive at the FILE* access level either. Finally, it is quite content with mis-cased include file names in C code.

NTFS is NOT case sensitive in any user-meaningful sense. I strongly doubt that it is case-sensitive underneath the covers either!

visor
Aug 4, 2003, 08:37 PM
The usual point and click user won't even notice that his system is now case sensitive, cuz he just clicks anyway. Not much he can spell wrong on this issue...

Anyone who is a little more into the System uses case sensitivity due to the 'case preserving' mode anyway.
Anyone migrating from Unix or Linux - obviously the targeted usergroup with potential to actually grow the user and developerbase for apple, knows and loves CaseSensitivity, mostly because it is a definite definition of a name.

Case matters most of the time for people in life, or would you like to be addressed with lower case name?

cnladd
Aug 4, 2003, 08:42 PM
Originally posted by jettredmont
Huh?

I believe you are quite mistaken there. I have NTFS running under Windows 2000 and Windows XP, and it's definitely not case sensitive at the DOS prompt. In fact, it's not case sensitive at the FILE* access level either. Finally, it is quite content with mis-cased include file names in C code.

NTFS is NOT case sensitive in any user-meaningful sense. I strongly doubt that it is case-sensitive underneath the covers either!

Nope, he's completely right. NTFS is a fully case-sensitive filesystem and has been since the very beginning -- this was a requirement in order comply with the POSIX standard. They touted this big-time to UNIX shops when it first came out.

The Windows APIs are incapable of seeing this, though -- that's by design. That's why you can't access it programmatically. Only tools/apps using the POSIX API can see it. I don't know if it's still around, but AT&T had some commercial UNIX utilities that were compiled for Windows and used the POSIX layer. You could actually 'mount' a volume with case sensitivity turned on. If you hade a FileName1.txt and a FILENAME1.TXT, they'd be distinct. Even Explorer was capable of showing both. Try to access one of them through Explorer, though, and it would crash. Accessing them through those POSIX tools were fine.

jettredmont
Aug 4, 2003, 08:50 PM
IMHO, I'd appreciate it if the file system were also "whitespace preserving but insensitive" ... No reason why "My File.doc" and "My File.doc" should be different thing ("MyFile.doc" is debatable).

Funny thing: Windows (XP)/NTFS will actually allow you to create, say, a directory named " ", but then, if you try to access it using Windows Explorer, you get an error message along the lines of "that folder is no longer there." Totally off-topic, yet somehow sorta halfway in an odd manner related.

cnladd
Aug 4, 2003, 08:52 PM
Originally posted by cnladd
Nope, he's completely right. NTFS is a fully case-sensitive filesystem and has been since the very beginning -- this was a requirement in order comply with the POSIX standard.

I don't know if it's still around, but AT&T had some commercial UNIX utilities that were compiled for Windows and used the POSIX layer.

Sorry for quoting myself. Wanted to doublecheck (should have done it before writing the previous post). Plus, I was curious if the AT&T tools were still around so I did some looking. :)

What they describe sounds much more stable than what I ran into:
http://techsupt.winbatch.com/TS/T000001036004F26.html

Here's the AT&T product. Looks like it's still around:
http://www.research.att.com/sw/tools/uwin/

jettredmont
Aug 4, 2003, 08:55 PM
Originally posted by cnladd
Nope, he's completely right. NTFS is a fully case-sensitive filesystem and has been since the very beginning -- this was a requirement in order comply with the POSIX standard. They touted this big-time to UNIX shops when it first came out.

The Windows APIs are incapable of seeing this, though -- that's by design. That's why you can't access it programmatically. Only tools/apps using the POSIX API can see it. I don't know if it's still around, but AT&T had some commercial UNIX utilities that were compiled for Windows and used the POSIX layer. You could actually 'mount' a volume with case sensitivity turned on. If you hade a FileName1.txt and a FILENAME1.TXT, they'd be distinct. Even Explorer was capable of showing both. Try to access one of them through Explorer, though, and it would crash. Accessing them through those POSIX tools were fine.

Hmmm ... I stand corrected ...

Yet, not exactly a model for OS X: most case-sensitive Unix apps (which will not be remounting your drives) still won't function under NTFS.

POSIX file system calls? I thought the FILE* bunch was POSIX, and I swear that case didn't matter on those ...

jettredmont
Aug 4, 2003, 08:59 PM
Originally posted by cnladd
Sorry for quoting myself. Wanted to doublecheck (should have done it before writing the previous post). Plus, I was curious if the AT&T tools were still around so I did some looking. :)

What they describe sounds much more stable than what I ran into:
http://techsupt.winbatch.com/TS/T000001036004F26.html

Here's the AT&T product. Looks like it's still around:
http://www.research.att.com/sw/tools/uwin/

Neat :) I might be able to use this some day ...

Okay, I think the discussion can return to its "normal" course now ...

Lead Belly
Aug 4, 2003, 11:19 PM
Originally posted by visor
The usual point and click user won't even notice that his system is now case sensitive, cuz he just clicks anyway. Not much he can spell wrong on this issue...

Anyone who is a little more into the System uses case sensitivity due to the 'case preserving' mode anyway.
Anyone migrating from Unix or Linux - obviously the targeted usergroup with potential to actually grow the user and developerbase for apple, knows and loves CaseSensitivity, mostly because it is a definite definition of a name.

Case matters most of the time for people in life, or would you like to be addressed with lower case name?

Man, if someone addressed me in all lower case letters, I just wouldn't know how to handle it. My head might esplode. Do you guys listen to yourselves? :)

It was asked by someone on page 1 and at page 5 the question still hasn't received an answer, really. What is the point? What would you want to use it for? Naming two distinct files "foo" and "Foo", as used in an earlier example, is not informative and actually inferior to naming it, say, "foo" and "foo2" (or virtually any other naming convention). The second example gives some sort of indication of chronology and parentage, one that is readily understood by nearly every human being on Earth. A year from now, who would possibly know the contents of file "foo" versus file "Foo". Case carries no meaning.

I'd be all for this if there was an example someone could give where the lack of case-sensitivity couldn't be accommodated easily another way. Changing a file system in a modern OS that is the height of usability to coddle to some 20 year old UNIX program that is the depth of usability doesn't seems like a good decision.

...and I don't believe the "option" is going to be all that optional.

zimv20
Aug 5, 2003, 12:01 AM
Originally posted by Lead Belly
What is the point? What would you want to use it for? Naming two distinct files "foo" and "Foo", as used in an earlier example, is not informative

that was my example. i wouldn't name files that way, either. and i'm not sure i can come up w/ an example that's going to make anyone say "aha! i've always wanted to name my files that way!"

rather, it seems more straightforward to me to have a one-to-one mapping of what the file is called and how i address it. right now, it's a many-to-one mapping (e.g. foo, Foo, FoO, FOo, fOO). if i type "fOO", and all i've got is "foo", i want my OS to tell me there's no such file. i don't want it finding what it _thinks_ i want. what if it gets it wrong?

Lead Belly
Aug 5, 2003, 12:04 AM
Originally posted by chomsky
Since it is clear that case sensitivity in HFS+ will be an option and not the default, it is curious that so many would rail so loudly against it.

The user base of MacOS is changing, and I think there are quite a few people who are afraid of that. The flood of tech-savvy Unix people into the fold has begun.

This is revitalizing Apple.. it should be embraced, not feared and reviled. Yes, perhaps in the days to come Mac users will no longer be synonymous with 'technically-challenged'. This will enrich, not dilute, the Mac community.

According to the slogans, it's a good thing to 'think different'. Well, we Unix people do. We think that B and b are different characters, and aren't thrown into mental disarray by the presence of more than one mouse button. We like to know more exactly what our computers are doing, so that we may control them better and make them serve our needs.

Please don't complain every time a concession is made for Apple's Unix folk. We're here to stay, so let's make friends...

c. thomas (another unix switcher)

Mac users are not technically challenged, they're technically liberated. We see the absurdity of performing a grep three times for the same file just because of case sensitivity. We want no part of it. I know I always enjoy visiting our IT Department and asking them to retreive some old cron file or data from a customer export file. They stare up at the ceiling tiles as they search their mind, like they're asking God to help them remember all the various upper and lower case possibilities.

I know of at least 8 companies I've done business with that have UNIX accounting systems, inventory systems, etc. You know what 5 of them do? They restrict case usage to only upper case to avoid the various problems that occur with strict case sensitivity. Even UNIX people are underwhelmed by strict case sensitivity.

Lastly, Apple's current method IS the Think Different method. This most recent UNIX incursion is the Think 30 Years Ago method. I'm hopeful Apple can implement this more artfully than it sounds.

grahamtriggs
Aug 5, 2003, 12:16 AM
Originally posted by visor
The usual point and click user won't even notice that his system is now case sensitive, cuz he just clicks anyway. Not much he can spell wrong on this issue...

Usual point and click user? There is *no* such thing as a user that points and clicks exclusively - for one thing, it is actually impossible (saving new files!!!)...

Anyone who is a little more into the System uses case sensitivity due to the 'case preserving' mode anyway.
Anyone migrating from Unix or Linux - obviously the targeted usergroup with potential to actually grow the user and developerbase for apple, knows and loves CaseSensitivity, mostly because it is a definite definition of a name.

Case matters most of the time for people in life, or would you like to be addressed with lower case name?

Case preservation - fine... there are plenty of good reasons for having properly cased file names... but that in itself does not require that the OS/file system be case sensitive... IMHO, there is *no* justification for case sensitivity in the file system... or, more specifically, there is *no* justification for allowing more than one file in a directory where the name only differs by it's case...

So by all means preserve case, be able to choose between sensitive and insensitive sorting options *at the time of taking a directory listing*...

I can even understand why case sensitive file access (ie. enforcing the correct case is entered to access a file) would be useful - as a security measure, for example...

But multiple files that differ *only* in case - no... for an OS/file system to allow that then it is (probably) fundamentally broken (I say probably, as there may be a highly specialised field for which it might be beneficial - in which case it should be a directory level option, that is off by default. There is still no justification on forcing that behaviour on 99% of users)...

Why are people vocal about it? Because it has to be ensured that it won't impact on 'normal' users... obviously more Mac users is a good thing... more software is a good thing... but if that software requires case sensitivity in the file system, then it is of no benefit to 'normal' users... and if that requirement starts creeping into software that they may rely on - ie. Apache - and / or existing Mac developers start pulling out because of problems caused by having multiple different environments, etc. then that isn't good for users either...

Lead Belly
Aug 5, 2003, 12:25 AM
Originally posted by zimv20
that was my example. i wouldn't name files that way, either. and i'm not sure i can come up w/ an example that's going to make anyone say "aha! i've always wanted to name my files that way!"

rather, it seems more straightforward to me to have a one-to-one mapping of what the file is called and how i address it. right now, it's a many-to-one mapping (e.g. foo, Foo, FoO, FOo, fOO). if i type "fOO", and all i've got is "foo", i want my OS to tell me there's no such file. i don't want it finding what it _thinks_ i want. what if it gets it wrong?

OK, I certainly understand wanting to limit unnecessary or extraneous information being returned.

Maybe it's the Foo (foo, Foo, FoO, FOo, fOO) that throws me off. If a file were named "custFile_08052003.txt" and you type "CustFile_08052003.txt", you would most certainly be looking for the same file, but simple case formatting prevents success. No?

Perhaps there are other means in which you would search for or correct this, I don't know.

cnladd
Aug 5, 2003, 12:36 AM
Originally posted by Lead Belly
Mac users are not technically challenged, they're technically liberated. We see the absurdity of performing a grep three times for the same file just because of case sensitivity. We want no part of it. I know I always enjoy visiting our IT Department and asking them to retreive some old cron file or data from a customer export file. They stare up at the ceiling tiles as they search their mind, like they're asking God to help them remember all the various upper and lower case possibilities.

I know of at least 8 companies I've done business with that have UNIX accounting systems, inventory systems, etc. You know what 5 of them do? They restrict case usage to only upper case to avoid the various problems that occur with strict case sensitivity. Even UNIX people are underwhelmed by strict case sensitivity.

Lastly, Apple's current method IS the Think Different method. This most recent UNIX incursion is the Think 30 Years Ago method. I'm hopeful Apple can implement this more artfully than it sounds.

Many UNIX accounting systems have been migrated from legacy platforms. Many people who use those accounting programs began by using legacy programs. It is common form to use all uppercase characters not because case sensitivity would be a problem, but because that was the norm on OS/360, OS/390, OS/400, VMS, MVS, and several other platforms.

As for "even UNIX people are underwhelmed", I suggest you go back and read the posts from UNIX people.

Finally, there are many methods that can be used to ignore case on the application level, even when searching through a case sensitive filesystem. Your example, that of three greps for one file due to case sensitivity is nonsense. Just add a '-i' to the command and, guess what? It ignores case.

Why won't folks get it through their heads that this is an option? I will (and have) fully admitted that case insensitivity is better for the average end-user. I happen to prefer my filesystems case-sensitive, however. If you don't like it that way, then I suggest you refrain from clicking that particular checkbox the next time you decide to format your hard drive.

And for the folks who think Apple's going to secretly screw you over and make everything case sensitive in the future: maybe. If they do, however, it will be well sheilded from the user. I hate to say it, but look towards the previous discussion regarding Windows' NTFS. Guess what? It's case sensitive. Most folks would have guessed that it's case-preserving (but ultimately case insensitive.) Why? Because the freakin' application layer and all appropriate interfaces have prevented the user from seeing into the filesystem at that level.

Look at what Apple has done to date: something very similar. As it stands, the average user won't have to deal with file permissions (oh, the dreaded chmod.) Most users won't have to deal with sticky bits, /tmp directories, the entire boot (/etc/rc.*) process, the open firmware. There's a powerful system underneath that Apple's done a pretty good job of obfuscating from day to day use.

Hell, I'm a hardcore UNIX guy and I only opened up my Terminal.app once in the first three months that I owned my iBook? Why? 'Cause I didn't have to.

The point is, if case sensitive filesystems become the norm in the future, there is technology that is already here that could easily avoid that. If, as I suspect, it doesn't become the norm (except for the Server version of Panther), then there's no point in the majority of this discussion.

As for why they stare up at the ceiling, I can tell you from personal experience that it's not 'cause they're searching their mind for a method of doing something (let alone anything having to do with such a minor issue as case sensitivity.)

Finally, for the person who wanted to know what purpose case sensitivity could possibly have in a filesystem: automation and programming. For the automation side, you've got numerous advantage such as more flexible sorting (A..Z, a..z or A..a, z..z -- yes, you often have a choice,) the ability to distinguish between the same file easily (as zim? explained, case preserving filesystems will always show you something they way you typed it, not the way it's stored,) and performance.

Performance? Possibly minimal but you either have the confusion I referred to above (where "ls Foo" and "ls foo" show the same file but in different cases) or you have the performance hit of always internally converting to a common case (which can be a huge pain if you're preserving case.)

The other benefit I mentioned was in programming, where case is often used as a standard in delineating function/methods from objects (et. al.) Depending on how the developer likes to do things, you can have files of a similar name on te same filesystem, in the same directory, where case is the only difference. Might seem asinine to a typical user, but to a programmer it makes perfect sense.

Sorry for the terribly long post, everyone. Like others, I keep on getting amazed that having the option for a case sensitive file system is such a big deal. To some people, it's exciting. Most others, I'd think, would care less -- if it ever becomes the default, I'd expect (and want) it to be shielded from regular folks and regular apps. Case insensitivity (and preservation) is better from a typical user's perspective -- I don't think that's in doubt. It's just that many of us are thrilled by the idea of having something that we feel is more advanced (and that we're more used to and comfortable working with.)

zimv20
Aug 5, 2003, 01:22 AM
Originally posted by Lead Belly
If a file were named "custFile_08052003.txt" and you type "CustFile_08052003.txt", you would most certainly be looking for the same file, but simple case formatting prevents success. No?

Perhaps there are other means in which you would search for or correct this, I don't know.

in command line, i'd never actually type that file name. there are many ways in the shell to get at that file that avoids the user typing the whole name.

e.g. i could use filename completion. if that were the only file that started w/ 'c', i'd type 'c' and hit escape twice. no problem. if i typed 'C' and hit escape twice, i'd get nothing and know there was something wrong.

i'd likely use wildcards. if i was inconsistent w/ my capitalization scheme and wasn't sure, i'd get at it with ?ust?ile*.txt or [Cc]ust*. <--- (forgive the bad spacing, courier font is messing it up)

or i could just ls and copy/paste the name. many possibilities.

zimv20
Aug 5, 2003, 01:33 AM
Originally posted by Lead Belly

Maybe it's the Foo (foo, Foo, FoO, FOo, fOO) that throws me off.

i thought of a concrete example where the case-insensitivity could cause a problem.

let's say you create a script called foo and stick it in your ~/bin. unknown to you, there's an executable in the system called Foo. it happens to be in a directory that's in your path.

you execute:
% foo
thinking you're running it out of your ~/bin. but guess what, you forgot to chmod 755 ~/bin/foo and the shell decides to execute Foo from that other place. wasn't that nice of the shell? it gave you a wrong result. what if that file does something nasty to your home directory. doh!

grahamtriggs
Aug 5, 2003, 02:03 AM
Originally posted by cnladd
And for the folks who think Apple's going to secretly screw you over and make everything case sensitive in the future: maybe. If they do, however, it will be well sheilded from the user. I hate to say it, but look towards the previous discussion regarding Windows' NTFS. Guess what? It's case sensitive. Most folks would have guessed that it's case-preserving (but ultimately case insensitive.) Why? Because the freakin' application layer and all appropriate interfaces have prevented the user from seeing into the filesystem at that level.

And in Explorer, if you have two files that only differ in case?.... Apple can shield case sensitive issues from the average users - but that can only go so far... if two files exist like this, what is 'application' layer going to do?

I don't particularly mind case-sensitive being an option, as long as it is the default - however, I still recognise that even that small concession may cause problems... so a UNIX app gets ported and expects a case-sensitive file system... a 'normal' user downloads it without really reading / understanding the notes, and trys to use it on a case-insensitive file system. What happens?

Finally, for the person who wanted to know what purpose case sensitivity could possibly have in a filesystem: automation and programming. For the automation side, you've got numerous advantage such as more flexible sorting (A..Z, a..z or A..a, z..z -- yes, you often have a choice,) the ability to distinguish between the same file easily (as zim? explained, case preserving filesystems will always show you something they way you typed it, not the way it's stored,) and performance.

Flexible sorting is a benefit that is gained from having a case PRESERVING file system. There s *no* need to allow two files that only differ by case to get this benefit. Nor is there any *need* to force people to always access a file with the exact case to get this benefit.

Performance? Possibly minimal but you either have the confusion I referred to above (where "ls Foo" and "ls foo" show the same file but in different cases) or you have the performance hit of always internally converting to a common case (which can be a huge pain if you're preserving case.)

If you only allow one file named with the letters 'f', 'o' and 'o' (in that order, any case), then the only confusion is if you expect 'Foo' in one directory but it is actually in another, yet there is still 'foo' in that directory... other than that, there is no confusion in mapping 'FOO', 'Foo', etc. to 'foo'. This is a far less common case, than having multiple files 'Foo', 'foo', etc. in one directory *by accident*, and not being able to determine between (which is also *far* more confusing - to the average user at least).

As for performance, implementations of case-insensitivity are pretty fast... remember that we are dealing with file access here, and even if case-insensitivity added 5 times the processing requirement, it is negligible compared to the speed of data transfer to/from the hard drive. (And it can easily be made faster than the generic 'compare any two strings insensitively' case)

The other benefit I mentioned was in programming, where case is often used as a standard in delineating function/methods from objects (et. al.) Depending on how the developer likes to do things, you can have files of a similar name on te same filesystem, in the same directory, where case is the only difference. Might seem asinine to a typical user, but to a programmer it makes perfect sense.

Case is often used - with good reason - in function method names, etc. And that can justifiably translate into a case preserving file system... however, that is *no* justification for two files whose name only differs by case... there is *no* situation where it makes perfect sense... initially developing an application, you might understand the difference - what about when you come back a year later to do maintenance, or another programmer has to take a look at the code? It is incomprehensible. *Any* programmer relying on having two files in the same directory that only differ by case deserves to be shot.

It's just that many of us are thrilled by the idea of having something that we feel is more advanced (and that we're more used to and comfortable working with.)

IMHO, I think you've (inadvertently) hit the nail on the head - 'you' are more used to case-sensitive file systems, and 'you' sometimes get unexpected results when the file system is insensitive. And possibly more important, you are restricted in what you can do when case preservation is implemented poorly.

A good implementation of a case preserving - although ultimately case insensitive - file system is the most usable form, and best fit for 99% of all users. And if you used that exclusively, you would almost certainly wonder why you ever liked case sensitive file systems.

zimv20
Aug 5, 2003, 03:15 AM
Originally posted by grahamtriggs

And if you used that exclusively, you would almost certainly wonder why you ever liked case sensitive file systems.

iow, the person who has used both and chose one can be wrong, whereas the person who's used only one must be correct.

grahamtriggs
Aug 5, 2003, 04:15 AM
Originally posted by zimv20
iow, the person who has used both and chose one can be wrong, whereas the person who's used only one must be correct.

Not at all...

So far, how many *well* implemented case preserving file systems have we seen?

ie. A system that will preserve the case exactly as you type it, allow you to optionally do flexible sorting both sensitive and insensitive, optionally allows you to choose between case sensitive and insensitive file access, with only one firm restriction - that filenames that only differ in case are not allowed?

We've seen poor implementations of case preserving, specifically with an underlying file system that is case sensitive, but with a fudged insensitive access layer above it, or case insensitive throughout, without the power to make use of the case information available - but not too many of the above.

Making the 'best' choice out of a restricted set of alternatives is not the same as the 'right' choice. Nor is making the 'best' choice *for you*...

As I said, there may be some very niche areas that really could make sensible use of truly case sensitive filing, however, how many of those would really be hampered by a *well* implemented case preserving system?

Pedro Estarque
Aug 5, 2003, 08:01 AM
just noticed this... Jaguar seems to be case sensitive when it comes to pass/log

cnladd
Aug 5, 2003, 08:26 AM
Originally posted by grahamtriggs
IMHO, I think you've (inadvertently) hit the nail on the head - 'you' are more used to case-sensitive file systems, and 'you' sometimes get unexpected results when the file system is insensitive. And possibly more important, you are restricted in what you can do when case preservation is implemented poorly.

A good implementation of a case preserving - although ultimately case insensitive - file system is the most usable form, and best fit for 99% of all users. And if you used that exclusively, you would almost certainly wonder why you ever liked case sensitive file systems.

You like case preserving. That's fine. You go on with your bad self 'cause I could really care less.

Please calm down. None of us here who prefer the case sensitive option are trying to claim intellectual superiority. We're not trying to convince you that it's better and that it's the only way to go. For some odd reason, though, you (and others) feel the need to do just that. That's what those of us who prefer case sensitive filesystems just don't get and why this argument has persisted -- why you (and others) suddenly feel the need to try to convince us that "your" way is "better". Throughout all of these various arguments, we've never done that to you. Please don't do that to us.

Please... please just get it through your head that I prefer case sensitive file systems. Stop trying to convince me that it's wrong or, if you can't, at least try to not be so insulting about it.

grahamtriggs
Aug 5, 2003, 09:11 AM
Originally posted by cnladd
You like case preserving. That's fine. You go on with your bad self 'cause I could really care less.

Please calm down. None of us here who prefer the case sensitive option are trying to claim intellectual superiority. We're not trying to convince you that it's better and that it's the only way to go. For some odd reason, though, you (and others) feel the need to do just that. That's what those of us who prefer case sensitive filesystems just don't get and why this argument has persisted -- why you (and others) suddenly feel the need to try to convince us that "your" way is "better". Throughout all of these various arguments, we've never done that to you. Please don't do that to us.

Please... please just get it through your head that I prefer case sensitive file systems. Stop trying to convince me that it's wrong or, if you can't, at least try to not be so insulting about it.

It's not about superiority, or being right or wrong. Your choice clearly isn't 'wrong' *for you*. This comes down to a couple of simple points:

1) There has yet to be made even a single, coherent reason why having two files in the same directory that differ only by their case is 'necessary'. By that I don't mean absolutely show-stoppingly vital, but where it would represent a significant issue.

2) No doubt there are a large number of people out there that choose case sensitive file systems, the fact still remains that it is not - and never will be - suitable for the majority of users, especially 'traditional' Mac users.

With regards the first point, a number of comments have been made regarding sorting of files, or reporting file not found for case errors - nothing there is impossible in a well implemented case preserving file system (some of these can easily be user configurable).

When compared to a well implemented case preserving system, a case sensitive file system gives one additional 'feature' - allowing multiple files that differ *only* in case - and comes at the expense of not being able to effectively offer case insensitive access as an option (Windows just about gets away with it, just because it is 'hard' - but not impossible - to create files that differ only in case). Is it really that important to you that you can do that?

zimv20
Aug 5, 2003, 11:04 AM
Originally posted by grahamtriggs

1) There has yet to be made even a single, coherent reason why having two files in the same directory that differ only by their case is 'necessary'.


1. foo.c is a c program. foo.C is a C++ program.

2. someone writes an app called ReadMe. in the same directory is its README file.

3. sccs is a command. SCCS is the directory in which the versioned files are placed.

jettredmont
Aug 5, 2003, 12:11 PM
Originally posted by zimv20
1. foo.c is a c program. foo.C is a C++ program.



Which is a braindead naming scheme. Common naming uses "cpp" or such for "C++" files. To begin with, the upper and lower-case "c" are too similar (look up ... It took me reading this twice to see your difference).

If any programmer on my team ever did this, they'd be fired. Period.


2. someone writes an app called ReadMe. in the same directory is its README file.


Again, a Very Poor Choice by said programmer.


3. sccs is a command. SCCS is the directory in which the versioned files are placed.

Same with CVS, and yet, seems like case-insensitive file systems work just great with cvs. You type "cvs" in a command context, and it runs cvs; you type it after "cd " and you go into the CVS subfolder. Is that really difficult? The only problem there might be is if you had a "CVS" folder in your "/bin" where "cvs" the application resides. Which would be ... well, beyond odd, to say the least. Which is why the "cvs"/"CVS" naming was approved in the first place ...

No, the Reason to Have Case-Sensitive File Names is this:

imagine a processing system which takes (case sensitive) alpha-numeric id's from some database collates a bunch of information about them, and dumps that information to disk for further processing. What should that system call each file it creates? Well, the natural answer is, "use the alpha-numeric ID, stupid!". But, in such a case, the case-sensitive IDs will cause a potential collision on a case-insensitive file system, which would require developing a scheme for differentiating upper-case from lower-case (primarily, use an "escape character" scheme like "_" before any previously-upper-case letter or "_" character). Such a filtering system makes searching for that file obviously more difficult as well.

Now, ideally, an human-visible identification scheme should not rely on case. It is always a problem, as, as others have pointed out, real life people do not explicitly differentiate between upper and lower case letters, even when spelling stuff out. However, we have a whole history of case-sensitive systems which, by design or accident, now contain identifiers which differ in nothing other than case.

Is it arcane? Yes. Should the "average user" have to deal with case sensitivity just for this very minor subset of the population? Of course not. Which is, of course, why Apple will make this an OPTION, not a REQUIREMENT, just like UFS always has been.

HFS+/case-sensitive does two things:

1) It allows a user to create a secondary disk which will hold both HFS meta-data and be a viable disk to house applications that require case sensitivity (you should know if you need such a thing).

2) It allows Apple to move forward with making sure Panther or some subsequent release can, itself, reside on such a disk (it currently can not live in UFS both because of the lack of HFS information and the case-sensitivity; there is no reason a well-written app should be case-sensitive, but, hey, stuff happens ...)

zimv20
Aug 5, 2003, 12:24 PM
Originally posted by jettredmont
Which is a braindead naming scheme. Common naming uses "cpp" or such for "C++" files.


sigh. yes, on windows, one had to use .cpp or .cc.


To begin with, the upper and lower-case "c" are too similar (look up ... It took me reading this twice to see your difference).

If any programmer on my team ever did this, they'd be fired. Period.


i'm sorry if you had trouble with it. i worked several unix projects w/ mixed languages and .C/.H worked just fine. no one ever complained. or got fired.

and i much prefer typing

% vi SomeLongFileName.[CH]
to

% vi SomeLongFileName.cpp SomeLongFileName.h

might be a small example, but add up many small things in unix and a developer gets a big time savings. i've been using it for nearly 20 years and would much rather develop in a case-sensitive environment.

and what of my earlier example of running the wrong program because of case-insenstivity?

grahamtriggs
Aug 5, 2003, 12:24 PM
Originally posted by zimv20
1. foo.c is a c program. foo.C is a C++ program.

foo.cpp is a C++ source file as well... cpp is a more meaningful extension than an uppercase C.

With C# being (independently) ported to multiple platforms, does the Unix community now advocate a typographical sensitive file system so that they can use an italicised C?

Mixing C and C++ source files in the same directory, *and* having them share the same 'root' name, is hardly intuitive, and should almost certainly be disallowed by coding standards.

The only case I can think of where this may be useful is when you need to wrap a C function within a C++ class for use in a C++ application (or vice versa)... even then, you may get into a mess with header files (at least in a case insensitive world, where .h is a standard for both C and C++ headers ;-)... And, almost certainly, you are better served by clearer naming of files that distinguish which is the wrapper, and which is being wrapped.

2. someone writes an app called ReadMe. in the same directory is its README file.

Interesting example - OK, a bit silly, but there may be a case for an executable name and document name to have the same 'root'.

However, this ReadMe / README convention is one that exists because it can, not because it makes any real sense to do so.

OK, it's quite reasonable when you are having to type at a terminal, but the world has moved on a bit. Most people point and click most of the time (even Unix people do a bit of it! ;-)... And the result of clicking on README is???

Sure, there are other ways of making the determining what to do with a file, but the standard is pretty much based on file extension... OK, it's a poor standard, but where is the harm in readme.txt?

3. sccs is a command. SCCS is the directory in which the versioned files are placed.

And the command and the directory *has* to be in the same place? Can't use SCCSDB or SCCS.DB, etc. for the directory? Can't use a better versioning system period? ;-)

I'm not saying that everything can come from a case-sensitive to case-preserving file system without changes... and yes, if you *have* things that rely on case-sensitivity, you don't want to suddenly be forced into case-insentivity / preserving.

But whilst that may be justification for an individual to want a case-sensitive file system (at a given point in time), that isn't the same as saying a case-sensitive file system is a genuinely useful thing. For the one single aspect that is different between *good* case preservation and true case sensitivity, no *genuinely* useful application has been mentioned. Yes, there *are* instances where this has been used. And even some reasonably sane reasons why (at the time) - but not to the extent where using the alternative represents anything more than mildly irritating change in working practises (not counting migration effort here!).

Supporters of case sensitive file system support in Mac OS X cite difficulties in moving Unix stuff that has (arbitrarily) taken 'advantage' of the case sensitive nature. I wouldn't mind allowing them case sensitivity as an option, *but*...

Just as there are problems with going from case-sensitive to case-insensitive, there are problems going the other way... and there are problems with supporting *both* styles concurrently...

What if someone takes your case-sensitive app and runs it on a case-insensitive file system? OK, maybe they should read the readme - but seeing as you've called it README, it's either been overwritten by the application, or doesn't have an application / icon attached to it so they can't just click on it ;-)

And what happens when you take someones case-insenstive app and run it on a case-sensitive file system.

What has been the Macs big selling point? 'It just works'. Doesn't quite 'just work' so well when the market is fragmented between case-sensitive and case-insensitive users. Whilst there are plenty of people that like case sensitivity, it is *NOT* suitable for the average user. It *NEVER* will be. Things don't 'just work' when you've got documents called 'hello', 'hEllo', 'Hello', can't just type 'hello' to open the file you saved as 'Hello', etc.

And the ironic thing? If case preservation was implemented properly, the *only* things you lose is the ability to have 'hEllo', 'Hello', etc. in the same directory... if you rely on that, then I hope you never have to go back to those files after not having looked at them, etc. for a long period of time (ie. 6-12 months)...

jettredmont
Aug 5, 2003, 12:26 PM
Originally posted by zimv20
i thought of a concrete example where the case-insensitivity could cause a problem.

let's say you create a script called foo and stick it in your ~/bin. unknown to you, there's an executable in the system called Foo. it happens to be in a directory that's in your path.

you execute:
% foo
thinking you're running it out of your ~/bin. but guess what, you forgot to chmod 755 ~/bin/foo and the shell decides to execute Foo from that other place. wasn't that nice of the shell? it gave you a wrong result. what if that file does something nasty to your home directory. doh!

Yeah, but that has nothing to do with case sensitivity (a "foo" executable anywhere in your path would do the same thing) and more to do with proper PATH usage (when in doubt, use "which" or specify the full path!).

jettredmont
Aug 5, 2003, 12:34 PM
Originally posted by zimv20
in command line, i'd never actually type that file name. there are many ways in the shell to get at that file that avoids the user typing the whole name.

e.g. i could use filename completion. if that were the only file that started w/ 'c', i'd type 'c' and hit escape twice. no problem. if i typed 'C' and hit escape twice, i'd get nothing and know there was something wrong.

i'd likely use wildcards. if i was inconsistent w/ my capitalization scheme and wasn't sure, i'd get at it with ?ust?ile*.txt or [Cc]ust*. <--- (forgive the bad spacing, courier font is messing it up)

or i could just ls and copy/paste the name. many possibilities.

Wow, seems like a lot of work for a reasonably common situation! And it still assumes that you only sometimes swap case in two of the characters, not, say, all of them like "CUSTFILE_2019384210"!

Filename completion would work fine if the alphabetics were at the end of the name, but not in the above example. Especially in the (common) case where uniquely-identifying information about the file is at the end of the filename instead of the beginning (which makes sense in many, many situations).

I think it is a given that if you have "CustFile_19028714.txt" in your folder you also have at least a hundred other similar files.

In such cases, if you are in the command line to begin with, you want a quick and efficient access. Looking up a file name in a list is not quick or efficient; typing in regexp's is not quick or efficient. You know you are looking for a "Customer File" ("cust file") and that the number is "19028714". You can type that in in less than two seconds, or you can dink around in a case-sensitive file system trying to get it right for thirty seconds.

zimv20
Aug 5, 2003, 12:45 PM
Originally posted by jettredmont
Yeah, but that has nothing to do with case sensitivity (a "foo" executable anywhere in your path would do the same thing) and more to do with proper PATH usage (when in doubt, use "which" or specify the full path!).

i'll use a more concrete example than "foo": a programmer writes the resource manager for his project. he names it RM but, again, forgets to chmod.

now he executes:

% RM ResourceManager.config


and his config file disappears. oops.

zimv20
Aug 5, 2003, 12:50 PM
all my examples come from years of doing unix development where having case sensitivity seems a natural way to go.

i'm not going to convince anyone that having case sensitivity is strictly necessary. demanding examples of necessity is an easy argument to make, and i could counter that osx is unnecessary (after all, we've all computed w/o it).

in the command line world, especially when developing, case sensitivity is a nice to have. and standard unix usage has grown up w/ it where case is expected to be a certain way (e.g. SCCS, README, vi, root are standard, but sccs, readme.txt, VI, Root mean something else).

w/ panther, we'll each get our own way. i'll choose case sensitivity.

jettredmont
Aug 5, 2003, 12:51 PM
Originally posted by cnladd
And for the folks who think Apple's going to secretly screw you over and make everything case sensitive in the future: maybe. If they do, however, it will be well sheilded from the user. I hate to say it, but look towards the previous discussion regarding Windows' NTFS. Guess what? It's case sensitive. Most folks would have guessed that it's case-preserving (but ultimately case insensitive.) Why? Because the freakin' application layer and all appropriate interfaces have prevented the user from seeing into the filesystem at that level.


I agree 100%. Apple would never foist system-wide case sensitivity on us users. On the other hand, these discussion boards thrive on worrying about how Apple might screw us over next, so ...


The other benefit I mentioned was in programming, where case is often used as a standard in delineating function/methods from objects (et. al.) Depending on how the developer likes to do things, you can have files of a similar name on te same filesystem, in the same directory, where case is the only difference. Might seem asinine to a typical user, but to a programmer it makes perfect sense.


Even to a programmer, it doesn't make sense for, say, a single object to have a constant called "RED" and a member called "red" and a method called "Red". "Just use 'red' for that." "'RED'?" "Yeah, 'red'." "Okay."

Case is often used as a hint of what a token represents (constant, method, variable, etc), just as "reverse hungarian notation" (aside: anyone know why it is calle this?) is often used to distinguish member variables from passed variables variables of different types from each other.

Speaking of RH notation, it is just as silly to have these three variables:

enum m_eRed;
int m_iRed;
string m_sRed="Red";

For, I should hope, obvious reasons (like capitalization, RH notation artifacts are stripped in programmer-to-programmer conversations and all three of the above would correctly be refered to as "the member variable 'Red'".)

In other words, the difference is between language-legal in Lint-friendly. A good Lint should catch both of the above examples, as it should check for case-sensitivity ever being used to distinguish two or more tokens in any single scope.

cnladd
Aug 5, 2003, 12:51 PM
Originally posted by grahamtriggs
...cpp is a more meaningful extension than an uppercase C.

Not to folks that have been working with C/C++ programs on UNIX for many years. I've only begun seeing *.cpp in the last few years. To me, 'cpp' is a C preprocessor. Just open up your terminal and do a 'man cpp'.

...Mixing C and C++ source files in the same directory, *and* having them share the same 'root' name, is hardly intuitive...

Again, not if you're used to the practice of doing that. If you're used to working with a case sensitive file system and you've been working under this standard then it makes perfect sense and is easily intuitive.

...but the standard is pretty much based on file extension...

Excuse me? Not on UNIX. File extensions didn't start becoming really popular until DOS/Windows compatibility became necessary. Even then, many "extensions" weren't really that, they were just common naming conventions.

...no *genuinely* useful application has been mentioned. Yes, there *are* instances where this has been used...

Of course not. We're not talking about user-level applications here. I could personally care less whether Word saved its files in a case sensitive manner (and, to me, it would be annoying if it did.) I'm talking about the typical command line tools that I use, typically located in /usr/bin and /usr/local/bin.

As far as useful, just because something doesn't fit your definition doesn't mean it isn't valid.

...And even some reasonably sane reasons why (at the time) - but not to the extent where using the alternative represents anything more than mildly irritating change in working practises (not counting migration effort here!)...

I'd prefer to not be mildly irritated every time I drop down to the command line, thank you.

...I wouldn't mind allowing them case sensitivity as an option...

Then why the hell do you continue to argue this, since this is exactly what we're talking about here?

...Whilst there are plenty of people that like case sensitivity, it is *NOT* suitable for the average user. It *NEVER* will be...

Have you read anything that's been said? That's been stated, by myself (and others who prefer case sensitivity) many times now.

I could care less about what filesystem the average user (or any other user, for that matter) decides to use. My use of the case sensitive filesystem doesn't impact you in any way. It doesn't impact the average user in any way.

Why do you continue to insist on something that, ultimately, has absolutely no impact on you? It's a benefit to some users. It should be a non-issue to all others.

cnladd
Aug 5, 2003, 12:57 PM
Originally posted by zimv20
i'm not going to convince anyone that having case sensitivity is strictly necessary.

I think it's agreed that no one here is trying to convince anyone that having case sensitivity is necessary. I've dealt with the lack of it just fine so far on Mac OS X and Windows.

What I don't understand is why people are trying to convince us that case sensitivity is frivolous and that case-preserving is what everyone should use when we've clearly stated a preference for sensitivity.

Foocha
Aug 5, 2003, 01:04 PM
Case Sensitive HFS+ is a replacement for the old HFS+. Sure, both will be options for a time, just like the way Apple allowed you to select HFS for a time, but let's be honest, the old HFS+'s days are numbers.

I think it's true to say that all major computing platforms have a case sensitive file system - including Windows and UNIX, (let's forget about Windows 95 shall we?)

The fact that at a file system level it is case sensitive needn't impact normal GUI users in any negative manner, but may benefit them as more UNIX apps will run on their systems.

Mac OS X is the Mac grown up - abandoning a case insensitive file system is simple a rite of passage. The Finder will still protect average users from creating two files with the same name in different cases.

zimv20
Aug 5, 2003, 01:08 PM
Originally posted by grahamtriggs

where is the harm in readme.txt?


everyone who's used unix command line will be looking for a README file. the harm is undoing decades of an accepted usage.

as mentioned, this move is supposed attract unix developers. they've already complained loudly about osx moving the locations of "standard" unix things. more than one will stay away if you make them use "readme.txt" or show them an A.OUT file.

another example: i've seen "cc" (c compiler) and "CC" (c++ compiler) in the same directory.

Foocha
Aug 5, 2003, 01:12 PM
NB: Windows 2000/XP file system is NTFS - this is case sensitive.

The fact that average users don't realise this demonstrates what a non-issue this really is for anyone except developers, for whom it's good news!

jettredmont
Aug 5, 2003, 01:23 PM
Originally posted by zimv20
i'll use a more concrete example than "foo": a programmer writes the resource manager for his project. he names it RM but, again, forgets to chmod.

now he executes:

% RM ResourceManager.config


and his config file disappears. oops.

First and foremost, try this in OSX (a case-preserving file system):

% echo "testing" > try.txt
% which RM
RM: command not found
% RM try.txt
RM: command not found
% rm try.txt
% ls try.txt
try.txt: No such file or directory

Which leads one to believe that your above scenario would not end in "ResourceManager.config" being deleted, but rather in "RM: command not found".

Moral: while non-built-in apps are case-insensitive on the command line, built-ins are not. This severely reduces the potential "damage" from a scenario as above.

Second: "RM" is an (obviously, one would think) poor choice of executable name. The programmer who does this would pretty quickly learn that he shouldn't name his application the same (sans case) as a system command. Darwin prevails again!

Also, "rm" would be just as poor of a name, and suffer the EXACT SAME pitfall, case-preserving or case-sensitive file system.

Again, "RM" might be a semi-passable albeit dangerous name for an app if there is only one person who will ever use it, but the instant one programmer has to say to another "use RM to do that" big fluttering red flags should go up, the programmer should slap his forehead, and maybe commit ritualistic suicide from the humiliation.

As a programmer, you should have a reasonable degree of care both when writing your app and when deploying it.

jettredmont
Aug 5, 2003, 01:31 PM
Originally posted by cnladd
Again, not if you're used to the practice of doing that. If you're used to working with a case sensitive file system and you've been working under this standard then it makes perfect sense and is easily intuitive.


Lest I be misinterpreted, I agree with what you are saying here. If you have been working this way for years, that's enough reason to continue (so long as this fits in with the other people on your team if you have one), and enough reason for Apple to provide this as an option.

I just don't want young, impressionable programmers to pick up you old-timers' bad habits regarding case sensitivity ... There's very little reason, from a top-down design perspective, to really want to use case sensitivity to distinguish tokens (be it file names or within code) from one another, aside from "that's just how I've always done it".

cnladd
Aug 5, 2003, 01:45 PM
Originally posted by jettredmont, referring to a programmer naming an executable "RM" or "rm"
As a programmer, you should have a reasonable degree of care both when writing your app and when deploying it.

Lesson to be learned here. This is also one of the reasons why sysadmins and developers clash, and why your above statement (while true) isn't always how things work:

I once wrote a script and stuck it in a cron job. Its purpose was to scan the disk and remove all files named 'core'. Everyone knows that when an app crashes and dumps core it ends up with a file named core. Developers will often use these to see where the errors are, but won't always delete them when they're done.

'Sides, other apps also dump core. It's considered good practice to removed. My script removed core files that were two weeks old or more.

A developer decided to name his new executable "core". Not only that, his main source file was also called core. He built to a different target so he never ran into naming issues. Seemed reasonable to him.

You can tell where this ends: it got deleted. He knew what core files were. He knew they got deleted after two weeks. To him, though, it wasn't a core file -- one was an executable, one was a source file.

Moral 1: Make sure (using 'file') that your core files are really core dumps before you delete them.

Moral 2: What may seem like common sense and best practice to you may not seem like it to the other person. Never assume. Everyone's got their own way of doing something.

cnladd
Aug 5, 2003, 01:52 PM
Originally posted by jettredmont
Lest I be misinterpreted, I agree with what you are saying here. If you have been working this way for years, that's enough reason to continue (so long as this fits in with the other people on your team if you have one), and enough reason for Apple to provide this as an option.

Thank you.


I just don't want young, impressionable programmers to pick up you old-timers' bad habits regarding case sensitivity ... There's very little reason, from a top-down design perspective, to really want to use case sensitivity to distinguish tokens (be it file names or within code) from one another, aside from "that's just how I've always done it".

I agree with that completely. That's why I personally like the Windows NT/2000/XP model -- I don't know of a single Windows developer (by that I mean one who uses Windows APIs) that knows that NTFS is case sensitive. It's a benefit for running POSIX apps, but that's it -- and I've only seen that done once, and not in production.

I look at the case sensitive version of HFS+ the same way.


I just don't want young, impressionable programmers to pick up you old-timers' bad habits...

Yes, I've got bad habits. I don't want impressionable, young programmers to pick them up... but "old-timer"? :P

zimv20
Aug 5, 2003, 01:55 PM
Originally posted by jettredmont

% echo "testing" > try.txt
% which RM
RM: command not found
% RM try.txt
RM: command not found
% rm try.txt
% ls try.txt
try.txt: No such file or directory

Which leads one to believe that your above scenario would not end in "ResourceManager.config" being deleted, but rather in "RM: command not found".


yes! and this led me to an interesting discovery: the behavior of the shell is different based on which way the capitalization is "going."

my RM->rm example turns out to not work. you're right: "command not found."

but: if /bin/rm were actually /bin/RM, and "rm" was your local unexecutable file, it would execute /bin/RM and _not_ give you "command not found."

weird, eh?

(my foo/Foo example from last night did work, for the reason i described above)

daveL
Aug 5, 2003, 02:00 PM
In my mind, this whole topic is simply about choice. If I want to adopt a file naming convention where .c is a C source file and .C is a C++ source file, why shouldn't I have that option? That's all Apple is doing. They are giving me the ability to choose.

I also disagree with those thinking that, over time, the case sensitive option will become the norm.

zimv20
Aug 5, 2003, 02:06 PM
Originally posted by jettredmont

I just don't want young, impressionable programmers to pick up you old-timers' bad habits regarding case sensitivity ... There's very little reason, from a top-down design perspective, to really want to use case sensitivity to distinguish tokens (be it file names or within code) from one another, aside from "that's just how I've always done it".

i think there is a reason -- it's a reasonable way of doing things. i can't think of a single example where case sensitivity caused a problem, but i've pointed out an example where it case insensitivity can cause a problem.

this actually boils down to a more philosophical argument which can be illustrated by using the MVC (model view controller) model.

when i develop, i name things the way i want -- i don't want unnecessary OS restrictions. README is a good example of this. that naming convention is my model. (note that such naming is legal in osx today).

i want my viewing mechanism to reflect my model. and in osx, in most cases it does (the finder shows README, 'ls' shows README). but, someone could implement a view that shows everything as lower-case (i.e. readme). that would annoy me, but be perfectly legal in a case insensitive environment. and, as i have demonstrated, there are ways the shell could give you a wrong result.

zimv20
Aug 5, 2003, 02:09 PM
i just found another way to ******* yourself:

[~] > touch foo
[~] > ls -il foo
2677670 -rw-r--r-- 1 steve staff 0 Aug 5 14:06 foo
[~] > touch bin/Foo
[~] > ls -il bin/Foo
2677671 -rw-r--r-- 1 steve staff 0 Aug 5 14:06 bin/Foo
[~] > mv foo bin
[~] > ls -il bin/?oo
2677670 -rw-r--r-- 1 steve staff 0 Aug 5 14:06 bin/foo
[~] >


what happened bin/Foo? in normal unix, i'd expect both files to be there. and the different inode numbers prove they're not the same file.

grahamtriggs
Aug 5, 2003, 04:25 PM
Originally posted by zimv20
i'll use a more concrete example than "foo": a programmer writes the resource manager for his project. he names it RM but, again, forgets to chmod.

now he executes:

% RM ResourceManager.config


and his config file disappears. oops.

So he has called it RM, presumably because he realises there is another command that already exists called rm.

OK, so there is an advantage in case-sensitive *matching*. BUT - it does *NOT* require a case sensitive file system to do this - only a case *preserving* file system - and an option to choose between sensitive / insensitive matching.

And if you know there is a command rm - and, especially knowing what it does - why on earth would you ever call your own application RM, Rm or rM? A faulty shift key, or forgotten caps lock, and you can easily inadvertantly be running 'rm' - case sensitive file system or not...

zimv20
Aug 5, 2003, 04:29 PM
Originally posted by grahamtriggs

And if you know there is a command rm - and, especially knowing what it does - why on earth would you ever call your own application RM, Rm or rM? A faulty shift key, or forgotten caps lock, and you can easily inadvertantly be running 'rm' - case sensitive file system or not...

ahhhh, sweet unix. the power to very quickly completely ******* yourself.

grahamtriggs
Aug 5, 2003, 04:43 PM
Originally posted by zimv20
i'm not going to convince anyone that having case sensitivity is strictly necessary. demanding examples of necessity is an easy argument to make, and i could counter that osx is unnecessary (after all, we've all computed w/o it).

See last comment.

in the command line world, especially when developing, case sensitivity is a nice to have. and standard unix usage has grown up w/ it where case is expected to be a certain way (e.g. SCCS, README, vi, root are standard, but sccs, readme.txt, VI, Root mean something else).

Well, yes - in the command line world, '.txt' is just four extra letters to type - you still end up typing the program name first - ie. vi README... It's only with a GUI that '.txt' makes sense - for launching an associated program just by clicking on the file.

I can see where case preservation comes in handy - if you don't have '.txt', then README has a conventional meaning... and I can see where preserved case can be used in advanced ways (ie. sorting)... Even for command line development though, I still can't see why it is beneficial to have to type vi README, rather than just vi readme - but maybe that's just me.

w/ panther, we'll each get our own way. i'll choose case sensitivity.

Well, if that's the case, good luck to you. However I am still concerned about the implications of a 'significant' split between sensitive and insensitive file systems amongst users. What are you going to do / say when you download an application that has been developed by a user with an insensitive file system, and it trashes your system because it hasn't been tested on a sensitive file system? Or the other way round?

jettredmont
Aug 5, 2003, 04:59 PM
Originally posted by grahamtriggs
I can see where case preservation comes in handy - if you don't have '.txt', then README has a conventional meaning... and I can see where preserved case can be used in advanced ways (ie. sorting)... Even for command line development though, I still can't see why it is beneficial to have to type vi README, rather than just vi readme - but maybe that's just me.



All-caps file names stand out in a (traditional, non-colored) ls file listing.

Kind of like a flag saying "this it the clue to what all those other files mean".

Hence, "README", "LICENSE", "INFO", etc.

Personally, though, my favorite is "00index.txt" ... sits at the top of any file listing, says what it is, does what it says ...

Also, ".txt" isn't a problem these days (well, since at least the early '90's if not earlier) as the TAB key (or other key, depending on the specific shell) would fill that in quick as can be on any CLI besides DOS. Back then, you had to replace "command.com" with 4dos's command.com replacement to have file-name completion ...

point is: extra crap at the end of a file name doesn't add any time on most CLIs, any more.

grahamtriggs
Aug 5, 2003, 05:29 PM
Originally posted by cnladd
Not to folks that have been working with C/C++ programs on UNIX for many years. I've only begun seeing *.cpp in the last few years. To me, 'cpp' is a C preprocessor. Just open up your terminal and do a 'man cpp'.

Amusingly, the only references I can see in Stroustrup's C++ Programming Language use the extension .c - not .C or .cpp...

Again, not if you're used to the practice of doing that. If you're used to working with a case sensitive file system and you've been working under this standard then it makes perfect sense and is easily intuitive.

I'm not talking about knowing the differences between C and C++ files... the point is if you have foo.c and foo.C (or foo.cpp), it is likely that one is a 'wrapper' for the other. Question is, which is which? It is *not* intuitive by looking at it - you might get it if you are familiar with the code, but what if you don't look at that code for months, or someone else has to maintain it?

Excuse me? Not on UNIX. File extensions didn't start becoming really popular until DOS/Windows compatibility became necessary. Even then, many "extensions" weren't really that, they were just common naming conventions.

Graphic interfaces under Linux use extensions to associate files with applications. As does Max OS X. (And Windows). So the standard is pretty much to use extensions. Well at least to over 95% of all computer users ;-)

As far as useful, just because something doesn't fit your definition doesn't mean it isn't valid.

*My* definition is irrelevant. Useful is useful... take README vs. readme.txt - strip away all other concerns, and the difference between the two is negligible... but years of accepting README as a standard makes it 'preferable' (and vice versa)... But when 'most' users don't make a distinction in the case of file names, and that 'most' users prefer to use a graphical environment, where file extensions are used to automatically launch the appropriate program, which is more useful?

I'd prefer to not be mildly irritated every time I drop down to the command line, thank you.

You wouldn't be mildly irritated every time - you would be mildly irritated for the first couple of months.

Then why the hell do you continue to argue this, since this is exactly what we're talking about here?

Because giving people more options is not always the the best thing for them. People talk about 'Apple screwing us'... they won't... but, if there is a large split between case-sensitive and case-insensitive users, there is a very real risk of Apple screwing THEMSELVES. Look at the 'switch' campaign - based entirely on the system 'just working'... Why are so many Unix people interested in OS X - possibly because unlike the million and one Linux distributions, it actually works (without spending weeks configuring the bloody thing)??

If applications are being distributed that bugger up one half of the community - because of case sesnsitive / insensitive issues - then that could be a significant problem for Apple (and their users).

Why do you continue to insist on something that, ultimately, has absolutely no impact on you? It's a benefit to some users. It should be a non-issue to all others.

But that's the point. It *doesn't* have no impact on me. So, more Unix software gets ported to MacOS X - I download it and run it, and it hoses my system because it required a case sensitive file system - that's had no impact on me?

zimv20
Aug 5, 2003, 05:31 PM
Originally posted by grahamtriggs

It's only with a GUI that '.txt' makes sense - for launching an associated program just by clicking on the file.


unix relies on magic numbers to identify file types, not the extension.

I still can't see why it is beneficial to have to type vi README, rather than just vi readme


the benefit comes from the standard. right now, i can find all READMEs "below"
me:

% find . -name README -print

because there's a convention. as soon as someone decides to skirt convention by using README.txt or readme, i miss it. to me, it's as nonsensical as calling your makefile Makefile.txt. all it does is cause problems for everyone down the road.

What are you going to do / say when you download an application that has been developed by a user with an insensitive file system, and it trashes your system because it hasn't been tested on a sensitive file system?

i have a hard time imagining that happening, 'cuz my sensitive file system will preserve his Foo and my foo. the other way around, however...

grahamtriggs
Aug 5, 2003, 05:40 PM
Originally posted by cnladd
What I don't understand is why people are trying to convince us that case sensitivity is frivolous and that case-preserving is what everyone should use when we've clearly stated a preference for sensitivity.

No, what I am trying to convince you of is that if you choose sensitivity, and I choose insensitivity, and we both develop applications, there is a reasonable / significant risk that we will cause each other problems. That is something that the Mac community does *not* need... as much as having options is generally a good thing, having a single standard in this case is better (for the community - not necessarily for you or me).

grahamtriggs
Aug 5, 2003, 05:49 PM
Originally posted by Foocha
Case Sensitive HFS+ is a replacement for the old HFS+. Sure, both will be options for a time, just like the way Apple allowed you to select HFS for a time, but let's be honest, the old HFS+'s days are numbers.

Hmm... I think quite a few people will have a different opinion...

The fact that at a file system level it is case sensitive needn't impact normal GUI users in any negative manner, but may benefit them as more UNIX apps will run on their systems.

Simply not true. The *only* reason why a UNIX app would run *only* on a case sensitive FS (rather than a case preserving FS) is if it relied on having multiple files that differed only in case in a directory. If you have multiple files like that, then it *does* impact normal (GUI) users - especially when the rest of the system is built around insensitivity (or at least emulating it)... because a command issued in an insensitive manner for those files would apparently be 'random' in it's behaviour.

(NB: This is ignoring the issue of actually compiling the app in the first place, of course)

mvc
Aug 5, 2003, 05:49 PM
Originally posted by jettredmont
I just don't want young, impressionable programmers to pick up you old-timers' bad habits regarding case sensitivity ... There's very little reason, from a top-down design perspective, to really want to use case sensitivity to distinguish tokens (be it file names or within code) from one another, aside from "that's just how I've always done it".

Clearly this whole argument shows how different work habits learnt at an early stage on different systems tend to stick and be percieved as "right." But there is precious little solid evidence of a measurable universal "right" approach.

So I don't seriously expect programmers from the point and click RAD generation to favour any sort of arcane, cryptic, text-based conventions that require the user to keep half the operating system in their head.

They will do it only when they must, in a legacy sense of the word, comply.

Instead I expect they will prefer giving their tokens explicit names in line with the current best practices of their own favoured language/environment, or better yet create a nice shiny 3D quartz icon which animates in the dock.:p

grahamtriggs
Aug 5, 2003, 06:05 PM
Originally posted by zimv20
everyone who's used unix command line will be looking for a README file. the harm is undoing decades of an accepted usage.

In DOS/Windows there are decades of using file extensions. Mac has undone decades of using metadata to make a distinction based on extensions.

Case sensitivity is being welcomed because it allows porting of more things from Unix... but if portability is such a concern just choose to adopt a 'standard' that allows you to work in both environments.

OK, the standard could become README - but what's realistic... undoing decades of accepted usage for 95%+ of the entire computing market - or choosing to call your document readme.txt?

as mentioned, this move is supposed attract unix developers. they've already complained loudly about osx moving the locations of "standard" unix things. more than one will stay away if you make them use "readme.txt" or show them an A.OUT file.

Right. Unix developers have complained loudly about the moving of standard things. But this is something that was done to make a system that is usable for 'everybody else'.

Again, this is an important reason why Unix had not gained a 'significant' installed base before OS X - because they won't change a 'standard' to make things more usable (for 'average' users).

I don't see too many Unix people complaining about the growth in 'Unix' users thanks to OS X - but that has only come about by making it usable. If 'you' want a larger installed base, then 'you' need to fit in with how 'everyone else' wants to use their computers - because they aren't going to fit in with you, just because that is how 'you've' been doing it for decades.

grahamtriggs
Aug 5, 2003, 06:18 PM
Originally posted by daveL
In my mind, this whole topic is simply about choice. If I want to adopt a file naming convention where .c is a C source file and .C is a C++ source file, why shouldn't I have that option? That's all Apple is doing. They are giving me the ability to choose.

Because the choice doesn't just stop at how you wish to name your files! It has implications on every application that you run on your system.

If half the Mac community have their systems 'destroyed' because they ran some software that didn't correctly account for the behaviour of their file system, is that good for Apple, or the Mac community as a whole?

cnladd
Aug 5, 2003, 06:22 PM
Originally posted by grahamtriggs
No, what I am trying to convince you of is that if you choose sensitivity, and I choose insensitivity, and we both develop applications, there is a reasonable / significant risk that we will cause each other problems.

No there isn't.

If you develop apps, you'll be developing against the standard Mac OS X API's (Cocoa, IOKit, etc.) I'll be doing the same thing. Even compiling applications will compile against Apple-supplied headers and APIs. At that point, it becomes an issue of whether Apple will shield users against case sensitivity -- and I expect they will. They should.

If you decide to run a UNIX application that relies on case sensitivity, you're assumed to know what you're doing and, frankly, you're on your own. I don't expect the majority of Mac OS X users to start downloading random UNIX tools and, if they do, I'd expect that they're precompiled and prepackaged -- again, likely against the headers and APIs that Apple provides.

grahamtriggs
Aug 5, 2003, 06:25 PM
Originally posted by zimv20
i think there is a reason -- it's a reasonable way of doing things. i can't think of a single example where case sensitivity caused a problem, but i've pointed out an example where it case insensitivity can cause a problem.

You've demonstrated a problem that is caused by using your standard working practise. But if you know that can cause a problem, you just do something else.

You can't think of a single example where case sensitivity caused a problem - but you are thinking about it from the point of view of developing specifically for such a scenario. Other people will easily have problems where the case in their include statement doesn't match the case in the file system (as just one example).

There are problems *either* way, but nothing that an experienced user can't resolve.

The big difference is that you are not going to convince the 'average' user that 'Foo' and 'foo' should be different files - or that you can't load 'Foo' by simply typing 'foo'.

Which means if you can only have one standard - and there are *good* reasons why you should - the choice is clear.

grahamtriggs
Aug 5, 2003, 06:41 PM
Originally posted by zimv20
the benefit comes from the standard. right now, i can find all READMEs "below"
me:

% find . -name README -print

because there's a convention. as soon as someone decides to skirt convention by using README.txt or readme, i miss it. to me, it's as nonsensical as calling your makefile Makefile.txt. all it does is cause problems for everyone down the road.

Actually, if you re-read my post, it was vi README vs. vi readme - no mention of .txt - which means that in a case preserving system both vi readme, and your find command could happily co-exist ;-)

Although, yes - ultimately I would advocate the use of the extension. Thing is, you talk about standards, and you can say exactly the same thing about Windows - the ability to dir readme.txt /s

You use README because it is the standard on Unix... and so when you port your application to Windows, it's no longer the standard. And that will be the case for what - 95% of your users?

i have a hard time imagining that happening, 'cuz my sensitive file system will preserve his Foo and my foo. the other way around, however...

Potentially, it could easily happen - let's say I update the system, and replace the file 'rm' with 'RM' (the file has to be replaced because other parts of the OS have changed, and the old version doesn't work anymore)... on my system, 'rm', gets replaced with 'RM' - I only have the new version, and executing 'rm' works exactly as expected...

On your sensitive system, 'rm' hasn't been deleted, and you now have two files - 'rm' and 'RM'... you try to execute 'rm', and what happens - it attempts to run the broken version...

grahamtriggs
Aug 5, 2003, 06:50 PM
Originally posted by cnladd
No there isn't.

If you develop apps, you'll be developing against the standard Mac OS X API's (Cocoa, IOKit, etc.) I'll be doing the same thing. Even compiling applications will compile against Apple-supplied headers and APIs. At that point, it becomes an issue of whether Apple will shield users against case sensitivity -- and I expect they will. They should.

It is impossible to shield against case sensitive / insensitive issues and get it right 100% of the time.

Put simply, if I treat a name as insensitive, but there are two different cased files in the file system that match, what do you do?

Beyond that, it isn't even clear in what circumstances something should / shouldn't be shielded. Presumably, if you have chosen sensitive behaviour, you don't want to be shielded - so what APIs do / don't?

cnladd
Aug 5, 2003, 06:55 PM
Originally posted by grahamtriggs
In DOS/Windows there are decades of using file extensions. Mac has undone decades of using metadata to make a distinction based on extensions.

To me it's the other way around, especially since UNIX has been in existence for much longer than either DOS/Windows or the Mac.


Case sensitivity is being welcomed because it allows porting of more things from Unix... but if portability is such a concern just choose to adopt a 'standard' that allows you to work in both environments.

Why should UNIX (and by that, I don't just mean Linux and BSD, I also mean Solaris, HP-UX, AIX, UnixWare, Tru64, 4.4BSD, et. al.) change their standards in order to make it easier for folks to port an app to Mac OS X? Especially since Apple wants to make it easier for us to port apps to their platform.


OK, the standard could become README - but what's realistic... undoing decades of accepted usage for 95%+ of the entire computing market - or choosing to call your document readme.txt?

Personally, I'm going to continue calling my files "README" 'cause, guess what? Mac OS X doesn't rely on the extension. If I create a text file in 'vi' (which is what I create all of my text files in), Mac OS X rightly recognizes it as a text file.

But, back to your point: neither will have to happen. Apple isn't undoing anything. They're making it easier for people who work one way to coincide with people who work a different way. They're not just trying to make things easy for you. They're also actively trying to make their platform more attractive to traditional UNIX folks.


Again, this is an important reason why Unix had not gained a 'significant' installed base before OS X - because they won't change a 'standard' to make things more usable (for 'average' users).

Sorry to break this to you, but it's because UNIX has nothing to do with "average" users. It hasn't been until recently (the last 10 years) that UNIX has been available for desktops -- and, to me, that's still just a novelty.


I don't see too many Unix people complaining about the growth in 'Unix' users thanks to OS X - but that has only come about by making it usable. If 'you' want a larger installed base, then 'you' need to fit in with how 'everyone else' wants to use their computers - because they aren't going to fit in with you, just because that is how 'you've' been doing it for decades.

I don't pay much attention to the growth of "UNIX" due to Mac OS X. It's a non-issue to me. I don't look at it as making the UNIX installed base larger, I look at it as them making use of a proven, stable technology to base their operating system on. Apparently, so does Apple, since they have quite a bit of marketing that touts the stability of the operating system due to its UNIX underpinnings.

Apple's figures and quotes about being the largest installed base of UNIX workstations is meant to entice UNIX folks to the platform. They're courting us, not the other way around. They're responding to our requests. That's why we're making more and more use of the platform. That's why many of the UNIX administrators that work with me plan on making their next purchase a Mac.

Why should I fit in with how everyone else wants to use their computers when that's not how I want to use my computer? That's why I preferred UNIX, because it worked the way I wanted it to work. That's why I've been movign to Mac OS X, because Apple recognizes that. They're doing a fine enough job of fitting in with me.

cnladd
Aug 5, 2003, 07:02 PM
Originally posted by grahamtriggs
It is impossible to shield against case sensitive / insensitive issues and get it right 100% of the time.

Sorry, but Microsoft gets it right 100% of the time with their APIs. In order to use case sensitivity, you have to actively work with a different API that isn't desirable for any Windows developer to use. Applications compiled for use with that API aren't intended to be used by the average user -- their single, specific purpose apps intended for a select audience who specifically wanted the ability to use those apps.

I'd expect the same situation with Apple.

The onus is on them to provide an interface that works well with both uses, since they're the ones actively courting both sets of users.

mvc
Aug 5, 2003, 07:08 PM
Originally posted by cnladd
They're courting us, not the other way around. They're responding to our requests.

Last time I looked, this was a MAC forum, not a UNIX forum as such. Listen to yourself, and try to see what impression this gives to others about the legendary "arrogance" of UNIX users.

US and THEM? The Mac platform is THEM in your quote? Wake up, you are on the wrong forum! Presumably you use the platform because you like it, not because it flatters your ego?

cnladd
Aug 5, 2003, 07:25 PM
Originally posted by mvc
Last time I looked, this was a MAC forum, not a UNIX forum as such. Listen to yourself, and try to see what impression this gives to others about the legendary "arrogance" of UNIX users.

US and THEM? The Mac platform is THEM in your quote? Wake up, you are on the wrong forum! Presumably you use the platform because you like it, not because it flatters your ego?

Read back through the posts, please.

This started out with some folks being excited about having case sensitivity support and others telling those people that "it's bad".

Not just "it's bad", but "it's bad, you're wrong, and you should switch your work habits to match us."

I've never once responded with "my way is better than yours", and neither has anyone else who's been happy that case sensitivity is going to be an option.

I can't understand how someone would take the issue of a case sensitive option so seriously, and then go to the point of saying that people who use those filesystems are wrong. Wouldn't you be insulted if I told you that the way you did things all these years was wrong and that you should change your methods?

Up until my last post, every response I've made has been "this can coincide, this shouldn't be a big deal." My last post was a direct response to someone saying that I should change my standards and the way I work to comply with theirs -- I was pointing out that I didn't have to, since just the opposite was happening.

This isn't an "us" versus "them" in regards to Mac vs. UNIX. To me, this is about some Mac users not liking the fact that Apple is embracing UNIX more and, instead of taking it out on Apple is directly attacking the standards and traditional habits of folks who came from the UNIX side.

mvc
Aug 5, 2003, 07:58 PM
Originally posted by cnladd
Up until my last post, every response I've made has been "this can coincide, this shouldn't be a big deal." My last post was a direct response to someone saying that I should change my standards and the way I work to comply with theirs -- I was pointing out that I didn't have to, since just the opposite was happening.

This isn't an "us" versus "them" in regards to Mac vs. UNIX. To me, this is about some Mac users not liking the fact that Apple is embracing UNIX more and, instead of taking it out on Apple is directly attacking the standards and traditional habits of folks who came from the UNIX side.

I have followed this discussion from the beginning.

As I posted previously, a programmers methods are obviously largely an issue of personal taste and background.

I have no problem with well-managed case sensitivity per se.

My point was simply that the attitude implied by the use of US and THEM seemed very counterproductive if the people you are trying to encourage to embrace change are being bracketed into the category of THEM!

Otherwise, I agree with your arguments.

zimv20
Aug 5, 2003, 08:08 PM
Originally posted by grahamtriggs
Actually, if you re-read my post, it was vi README vs. vi readme - no mention of .txt - which means that in a case preserving system both vi readme, and your find command could happily co-exist ;-)



[~/tst] > mkdir tst2
[~/tst] > touch readme tst2/README
[~/tst] > find . -name readme -print
./readme
[~/tst] > find . -name README -print
./tst2/README
[~/tst] >


i.e. the find command doesn't find both


Although, yes - ultimately I would advocate the use of the extension.


why? unix gets along fine w/o them. and despite your protestations that osx has to adapt to the way windows does things, osx is based on unix -- not windows.

zimv20
Aug 5, 2003, 08:12 PM
Originally posted by mvc

My point was simply that the attitude implied by the use of US and THEM seemed very counterproductive if the people you are trying to encourage to embrace change are been bracketed into the category of THEM!


don't expect to get non-attitude from unix geeks.

mvc
Aug 5, 2003, 08:22 PM
Originally posted by zimv20
don't expect to get non-attitude from unix geeks.

Now now, kids we all gotta learn to get along. After all its not about the platforms, or the languages, its not even our likes & dislikes & habits. Its all about the USER, and brotherly luuve between all species of geeks</sermon>

jettredmont
Aug 5, 2003, 08:56 PM
Originally posted by grahamtriggs
Simply not true. The *only* reason why a UNIX app would run *only* on a case sensitive FS (rather than a case preserving FS) is if it relied on having multiple files that differed only in case in a directory. If you have multiple files like that, then it *does* impact normal (GUI) users - especially when the rest of the system is built around insensitivity (or at least emulating it)... because a command issued in an insensitive manner for those files would apparently be 'random' in it's behaviour.

(NB: This is ignoring the issue of actually compiling the app in the first place, of course)

Depends on the working sandbox for that file. If the file is housed in a folder where only that (or similar, case-sensitive, apps) look for it, and reasonably "difficult" to get to through normal means, then there is no harm in it. I mean, there's a whole bunch of magic hidden inside the /usr/ and /bin/ folders of OS X that no normal user should ever have to see, and OS X does a great job of shielding us from those details.

If App A is, in a particular folder, creating Foo and foo, and Apps B, C, and D then use those data files, which would likely mean that there are no creator codes or associations or icons or anything for Foo or foo in Finder, then that is, essentially, App A/B/C/D's sandbox. Going in with the Finder I'd expect to see one "Foo" (which could be the first one created, or could be the first or last lexographically: whatever). From A, B, C, and D, I'd see two apps (which, as has been pointed out on this thread, is exactly how NTFS/Win NT work).

Can I access "foo" if "Foo" is shown in Finder? Nope. Should I access "foo" if "Foo" is shown? That depends on a few things. First, if I were to delete the entire contents of the folder and the folder itself, I'd expect both "foo" and "Foo" to be gone. Second, if I were to go to Terminal and use Unix commands, I'd expect to see both files sitting there and have the ability to manipulate them both (iow, Terminal's shells should see the the file system as "smart" case-sensitive ... only show and require exact case when there are multiple possibilities). If I were to look at the folder in any other non-cased application, like Finder or through a Cocoa Open/Save dialog, I'd expect to see exactly one (which indeterminate) file.

Now, what would be neat-o cool to the extreme, were if Finder were to allow us to turn on "view case-sensitive file names" for a particular folder, so that when we go to that particular folder "foo" and "Foo" do show up ...

Can this be done? Yes. Would it work? Yes; it has been done and does work on other platforms. Will Apple do it? I strongly suspect so, at some future time. Will Apple make a case-sensitive file system the default for new Macs before such is made 100% transparent to the user? Absolutely not!

jettredmont
Aug 5, 2003, 09:06 PM
Originally posted by zimv20
the benefit comes from the standard. right now, i can find all READMEs "below"
me:

% find . -name README -print

because there's a convention. as soon as someone decides to skirt convention by using README.txt or readme, i miss it. to me, it's as nonsensical as calling your makefile Makefile.txt. all it does is cause problems for everyone down the road.


FYI, if you use "find . -iname readme\* -print" (three extra keystrokes...) instead you'll find it all the README, ReadMe, Readme, readme.txt, readme.doc and "readme please right now I need to be read!" files beneath your pwd.

[edit: forgot the escaping backslash ... brings the extra keystroke count up to 3 ... but loses bonus points for use of the backslash now ...]

zimv20
Aug 5, 2003, 09:57 PM
Originally posted by jettredmont
find . -iname readme\* -print

mmmmm.... unixy.....

never used the -iname switch. thanks for the heads up. and much more creative than use of the -or switch.

whooleytoo
Aug 6, 2003, 05:06 AM
Just curious, but what happens when Jaguar reads a case-sensitive HFS volume? Say, one that contains two folders called system and System. Will it choke? Or will it just refuse to mount it in the first place?

Mike.

grahamtriggs
Aug 6, 2003, 05:09 AM
Originally posted by cnladd
To me it's the other way around, especially since UNIX has been in existence for much longer than either DOS/Windows or the Mac.

It's not one way around or the other - both exist. If we are happy to continue with our polarised 'little' communities, then both can continue to exist in ignorance of each other. If we want the computing world to come closer together, make things 'easier' for everyone over all, then the standards need to come closer together.

Why should UNIX (and by that, I don't just mean Linux and BSD, I also mean Solaris, HP-UX, AIX, UnixWare, Tru64, 4.4BSD, et. al.) change their standards in order to make it easier for folks to port an app to Mac OS X? Especially since Apple wants to make it easier for us to port apps to their platform.

No reason at all. But if you want a larger installed user base, if you want UNIX desktop to be a reality (traditional 'UNIX' may not - but Linux does), then you need to change the standards - because the 'average' user isn't going to adopt the existing ones.

But, back to your point: neither will have to happen. Apple isn't undoing anything. They're making it easier for people who work one way to coincide with people who work a different way. They're not just trying to make things easy for you. They're also actively trying to make their platform more attractive to traditional UNIX folks.

No they aren't undoing anything - but they could be making a dangerous split in their user base. Look at the 'switch' campaign - it's based around the idea of a Mac 'just working'. What would even one report of a large section of the Mac user base having their systems trashed by an application / update do to that? If half the community uses case-sensitive, and half case-insensitive, that *COULD* happen.

Sorry to break this to you, but it's because UNIX has nothing to do with "average" users. It hasn't been until recently (the last 10 years) that UNIX has been available for desktops -- and, to me, that's still just a novelty.

Exactly - which is why it is a 'niche' OS... Linux may not be UNIX in the traditional sense, but it's desktop aspirations are hardly a novelty - but the reality will remain so unless they do more to obfuscate the technicalities of the OS from the user.

Why should I fit in with how everyone else wants to use their computers when that's not how I want to use my computer? That's why I preferred UNIX, because it worked the way I wanted it to work. That's why I've been movign to Mac OS X, because Apple recognizes that. They're doing a fine enough job of fitting in with me.

You shouldn't - just keep using your UNIX OS that shows no signs of 'sanitising' itself to allow for wider adoption, and don't worry about using Mac OS X / Windows (or porting applications to, etc.)

If MacOS X offers things that are appealing to you, then great - come across.. case-sensitivity would be beneficial to you - well fine, there is no problem in you as an individual choosing an *option* to have a case sensitive file system... the problem is, it wouldn't just be you - a significant split in how Mac users have their file systems configured is a recipe for problems later on. Even if it 99% of the time, there is no problem, it only takes *ONE* case of significant size to be very bad news. Do you really need this option that much?

grahamtriggs
Aug 6, 2003, 05:16 AM
Originally posted by cnladd
Sorry, but Microsoft gets it right 100% of the time with their APIs. In order to use case sensitivity, you have to actively work with a different API that isn't desirable for any Windows developer to use. Applications compiled for use with that API aren't intended to be used by the average user -- their single, specific purpose apps intended for a select audience who specifically wanted the ability to use those apps.

No. Microsoft gets it right 99.9% of the time. It gets it right, because virtually nobody bypasses the Windows API, so they don't bypass the case insensitive layer - so to all intents and purposes their file system is case preserving only.

What happens when someone uses the POSIX API and starts taking advantage of the case sensitive nature of the file system (ie. create Foo and foo) in the same directory - the case insenstivie layer doesn't get it right.

grahamtriggs
Aug 6, 2003, 05:31 AM
Originally posted by cnladd
This started out with some folks being excited about having case sensitivity support and others telling those people that "it's bad".

Not just "it's bad", but "it's bad, you're wrong, and you should switch your work habits to match us."

No - case sensitivity is not bad. Case sensitivity *IS* bad for the average user though. Macs have quite a lot of 'average' users.

Of course, case sensitivity is an option - so there is no immediate effect on 'average' users. But what were we saying before? Get more Unix people on board, and more Unix apps are ported to Mac OS X = good for Mac OS X. Ergo, 'average' users might use some of this software maybe? And what happens when it was expecting case sensitivity and found case insensitivity?

And all those Unix refugees... presumably they chose Mac OS X - and chose HFS+ (instead of UFS) so that they could gain access to all the great Mac software - which won't run because it was only tested on a case insensitive system. Ooops.

No - case sensitivity is *not* bad. But it *is* bad for the *majority* of users. And it *is* largely unnecessary (many of the benefits *can* be realised in a case preserving system). And it *is* bad to have a split between case insenstive and case sensitive users.

Case sensitivity is not bad - but adding case sensitivity to HFS+ creates more potential problems than benefits.

jettredmont
Aug 6, 2003, 10:16 AM
Originally posted by grahamtriggs
No. Microsoft gets it right 99.9% of the time. It gets it right, because virtually nobody bypasses the Windows API, so they don't bypass the case insensitive layer - so to all intents and purposes their file system is case preserving only.

What happens when someone uses the POSIX API and starts taking advantage of the case sensitive nature of the file system (ie. create Foo and foo) in the same directory - the case insenstivie layer doesn't get it right.

But, that's the point.

The needs (outside of just plain habit) for case sensitivity in filenames are quite small, and, generally, tools that are made to rely on case sensitivity are old, arcane tools that wouldn't interact well with a user modifying their files in the first place.

So, yes, putting multiple differentiated-by-case files in the user's "My Documents" folder would be bad, but usually such apps put their files in an out-of-the-way location that the user, for all intents and purposes, should really never see.

jettredmont
Aug 6, 2003, 10:32 AM
Originally posted by grahamtriggs
But what were we saying before? Get more Unix people on board, and more Unix apps are ported to Mac OS X = good for Mac OS X. Ergo, 'average' users might use some of this software maybe? And what happens when it was expecting case sensitivity and found case insensitivity?


The vast majority of UNIX applications do not, at run-time, rely on case sensitivity. Many rely on case sensitivity during the build process ("Makefile" vs "makefile", etc), although those with mainstream appeal are generally moving away from that ('cause it keeps them from doing a Windows port without cludgy tools). Most do NOT rely on case sensitivity while they are running, and of those that do, I'd venture to guess that NONE of them will ever land on your grandmother's iMac. These are specialty, in-house apps for the most part.

The thing is: if these specialty, in-house apps can't be ported over, then the companies that rely on them can't port over, and the other apps the company might touch don't get ported over, and that affects a lot more desktops than have to just deal with the in-house case-sensitive apps.


And all those Unix refugees... presumably they chose Mac OS X - and chose HFS+ (instead of UFS) so that they could gain access to all the great Mac software - which won't run because it was only tested on a case insensitive system. Ooops.


I would be very surprised if more than a handful of apps break on a case-sensitive file system, even without the Cocoa/Carbon layers being case-insensitive. I mean, if you are accessing the same file in two places of your app with different case that means that you've got two different strings in your application. If you have two different strings in your application it is most likely the case that you have string literals throughout your app. Now, many one-shot apps are loaded with string literals, yes, but any app coming out of a company with mopre than three people should be using some sort of global string repository (be that the i18n tools provided by the OS or your own concoction, I don't care). The admonition to not use string literals has been so strong for so long that there should by all rights be no one still developing with string literals embedded in their applications.

In other words, if an app breaks on case sensitivity, then it has far larger mantainability and stability problems, and you shouldn't be using it anyways.

Apps don't run on UFS because UFS doesn't preserve meta data like HFS+ does. Period.


No - case sensitivity is *not* bad. But it *is* bad for the *majority* of users. And it *is* largely unnecessary (many of the benefits *can* be realised in a case preserving system). And it *is* bad to have a split between case insenstive and case sensitive users.


Here's the thing: it's largely unnecessary, but where it's necessary, there's no alternative. It's not a "convenience item". It's a necessity. Not having it means you don't allow those developers on board.

From a project management perspective, if you have items that affect a small portion of users, but for them it makes your system unusable, you either have to justify losing customers (and customers are too hard to find to just be tossed aside without much consideration!) or you have to fix the system so that they can at least use it (although it might not be overly convenient). You tend to tackle these after the really big, affects-all-users items, but at the top of the "little things" list.

IMHO, OS X is moving on to the "little things" list now.

tim_bissell
Aug 6, 2003, 06:17 PM
quote:
Originally posted by arn
I think the problem people have with it is that in our day to day lives.... we do not treat things as case-sensitive.

In conversation - Bob, bob and boB are irrelevant. It's all the same.

---

Yeah, but my computer never speaks to me. Bob bob and boB mean different things when written - Bob is a person's name, bob is an archaic slang word for an old unit of English currency, or a verb describing an up and down motion. boB doesn't really mean anything.
In other languages (Mac does other languages, even if english speakers mostly don't) case is very important. Adding it back as an option is good.

Also as a programmer I can't see any reason why changing case sensitivity would require a partition reformat. HFS+ is already case preserving, so the info is there on the disk. I imagine it will be an option a bit like journalling, which can be switched on without any changes to the filesystem structure.

grahamtriggs
Aug 7, 2003, 01:30 AM
Originally posted by tim_bissell
Also as a programmer I can't see any reason why changing case sensitivity would require a partition reformat. HFS+ is already case preserving, so the info is there on the disk. I imagine it will be an option a bit like journalling, which can be switched on without any changes to the filesystem structure.

Yes, going case-insensitive to case-sensitive could effectively be a non-destructive option... however, that kind of implies that the reverse operation is legal as well... What happens if you have a case-sensitive file system, create files 'Foo' and 'foo' in the same directory, then switch back to case-insensitive?

Also, as someone else mentioned, what about using the volume on Jaguar / a case-insensitive system? There are potential issues there, and maybe this will be used to stop unaware OSes from mounting the volume?

Lastly, maybe it is because they don't want it to be too easy to use case-sensitivity... so, if you want to use it, then you have to know enough about your system to be able to reformat it *and* select the correct format, and actively make the decision to do so.

If we were talking about case-sensitive vs. case-insensitive *matching*, with the file system *always* being case preserving but ultimately case-insensitive (ie. never allowing 'Foo' and 'foo' in the same directory) then that could easily be a non-destructive option.

The latter is definitely my preferred choice. I can see that there are enough people that need/want case-sensitive matching, and it is such a low risk, that it can justify inclusion as an option. IMHO though, I still don't see that there are enough people that *require* the ablity to store 'Foo' and 'foo' in the same directory that it can be justified against the *potential* problems (even if they are largely theoretical)

tim_bissell
Aug 7, 2003, 05:41 AM
Yes, going case-insensitive to case-sensitive could effectively be a non-destructive option... however, that kind of implies that the reverse operation is legal as well... What happens if you have a case-sensitive file system, create files 'Foo' and 'foo' in the same directory, then switch back to case-insensitive?


Easy - remember we are modifying the filesystem code; when in 'case-insensitive' mode have the filesystem code map clashing names onto something different; e.g.

Foo -> Foo
FOO -> Foo-1

Ugly, but it does the job. This could also work for remote mounting of filesystems.
Classic mode can be fixed this way as well. Could also go into a point release of Jaguar.
If you set case-sensitive true on your filesystem and boot into an older MacOS, well... you get what you deserve ;-)


If we were talking about case-sensitive vs. case-insensitive *matching*, with the file system *always* being case preserving but ultimately case-insensitive (ie. never allowing 'Foo' and 'foo' in the same directory) then that could easily be a non-destructive option.
The latter is definitely my preferred choice. I can see that there are enough people that need/want case-sensitive matching, and it is such a low risk, that it can justify inclusion as an option.


But that would defeat the main pragmatic object of allowing easier porting of Unix (and Java) programs.


IMHO though, I still don't see that there are enough people that *require* the ablity to store 'Foo' and 'foo' in the same directory that it can be justified against the *potential* problems (even if they are largely theoretical)


YO indeed, I'm sure a lot of speakers of other languages (Germans for instance) would prefer case sensitivity. Indeed German grannies may well be confused if they save a file called 'Datei' in a directory, and it overwrites their 'datei' file.

I am puzzled as to why HFS is case-insensitive but not whitespace insensitive - surely it is harder to distinguish 'My folder' and 'My folder' than 'My folder' and 'my folder'? Any objections to adding whitespace insensitivity to HFS, surely this will make the Mac even more intuitive?

grahamtriggs
Aug 7, 2003, 06:25 AM
Originally posted by tim_bissell
Easy - remember we are modifying the filesystem code; when in 'case-insensitive' mode have the filesystem code map clashing names onto something different; e.g.

Foo -> Foo
FOO -> Foo-1

Ugly, but it does the job. This could also work for remote mounting of filesystems.

Ugly, and impossible... two files is a trivial example... how about:

'foo', 'Foo', 'fOo', 'foO', 'FOo', 'fOO', 'FOO'

So that might be:

foo -> foo
Foo -> foo-1
fOo -> foo-2
foO -> foo-3
etc.

So, what has 'fOO' been translated into? Is it dependant on the number of files that are being translated? What about the applications that are still referencing 'fOO' - is it some special hashing algorithm that is alway guaranteed to match, if so what happens when there is no need for it... how do you tell there is no need for it?

But that would defeat the main pragmatic object of allowing easier porting of Unix (and Java) programs.

Well, Java by it's very nature - well, Sun's insistence - is portable by nature... so you shouldn't *ever* be relying on a 'quirk' of a particular file system - and they may even prevent you from doing so (without resorting JNI).

YO indeed, I'm sure a lot of speakers of other languages (Germans for instance) would prefer case sensitivity. Indeed German grannies may well be confused if they save a file called 'Datei' in a directory, and it overwrites their 'datei' file.

But then don't the overwhelming majority of non-English speaking people - and particularly 'average' users - already use case insensitive file systems without incident?

I am puzzled as to why HFS is case-insensitive but not whitespace insensitive - surely it is harder to distinguish 'My folder' and 'My folder' than 'My folder' and 'my folder'? Any objections to adding whitespace insensitivity to HFS, surely this will make the Mac even more intuitive?

True, whitespacing can be more awkward - and whilst it may cause *some* problems with existing apps / files, it may well be a good thing to introduce. However, whitespace insensitive matching is a significantly more intensive algorithm than case insensitive. Which - if for no other reason - is big enough for it to have not been done before now. And possibly still shouldn't. However, what would be good is to have optional whitespace normalisation and insensitivity within an applications load / save commands.

tim_bissell
Aug 7, 2003, 06:52 AM
Ugly, and impossible... two files is a trivial example...

True, two files is trivial - but this is computing; nothing is impossible, there are always ways around problems, even if it slows things down. I can think off-hand of a few ideas; all you have to do is sit down and think through the use-cases and come up with a solution (trust me, I'ma programmer).

Well, Java by it's very nature - well, Sun's insistence - is portable by nature... so you shouldn't *ever* be relying on a 'quirk' of a particular file system - and they may even prevent you from doing so (without resorting JNI).


Unfortunately Sun already relied on case-sensitivity. Java has case-sensitive Class names (TimeZone is a different class to Timezone) unfortunately Sun chose to insist that Filenames for Java source files match their classnames, so TimeZone source must be in a file called TimeZone.java, and compiles into a file called TimeZone.class. We were talking about porting applications; if someone foolishly chose to name two classes TimeZone and Timezone, the code would not compile without change on HFS+ (the binaries, once compiled correctly would be fine as they are hidden inside a case-sensitive archive file.


But then don't the overwhelming majority of non-English speaking people - and particularly 'average' users - already use case insensitive file systems without incident?


They've adapted to its quirks, but it is not intuitive, which is the the thrust of the 'case-insensitive' proponents' argument.

It is a bit of a 'you say tomayto, I say tomahto' debate, so ultimately fruitless (ouch).

If it is an option, even one which cannot be switched off, then it will prove very useful - and I for one will get rid of my UFS partition on which I compile all my 'unix' and Java code.