Those who don't care would soon care if (for example) they find it impossible to copy a set of files from one device to another.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Made Me Buy a Windows HP Workstation
- Thread starter Mark Holmes
- Start date
- Sort by reaction score
Those who don't care would soon care if (for example) they find it impossible to copy a set of files from one device to another.
I'm not sure what you're talking about here. I've been using case-sensitive file systems on MacOS X for many years, and it works perfectly. When I get a new Mac, the first thing I do is reformat the drive as case-sensitive and then install the OS. There are a few applications that apparently won't install on a case-sensitive file system, but this has not affected me since this is not the case with anything I currently use. If it was a problem, all I would need to do is create a partition and format it to be case insensitive and put it there.
I was just giving the heads up. Not all may know this. And they may have applications that won't work. Or they may not want to partition the drive as well. You have your comfort levels and accepted levels of added work to do things, others may not. I for example when wanting a more pure and original Linux/bsd/unix experience run vm's with cli only installs. If going for pure install, make it pure. SSH in and type. I'll be nice, they can use nano as editor when needed. I do. I hate vi.
The intent was not having a user (My advice assumes others may read as well) do this, install that application and then go wtf, why won't this application work. Information given of potential issues, on the user to go from there. to their levels of comfort.
Does Apple offer a "case preserving" filesystem like Windows?
That means, if you create a file named FoO.BaR it is stored as FoO.BaR - and if you list it the file shows up as FoO.BaR.
However, if you edit "foo.bar" or "Foo.Bar" you'll read and write "FoO.BaR".
That means, if you create a file named FoO.BaR it is stored as FoO.BaR - and if you list it the file shows up as FoO.BaR.
However, if you edit "foo.bar" or "Foo.Bar" you'll read and write "FoO.BaR".
Great! Why would anyone want anything else!?
Case-sensitive filesystems (and shells) are relics of the time of 110 baud modems and systems with main memory measured in Kibibytes - and when ending a filename with ".c" meant something different than ending it with ".C".
Today a single filename can be too long to fit in the RAM of one of those systems, yet we still are crippled by early 70's conventions.
Yes, and .C is a suffix for C++ source and .c is a suffix for C source. They aren't the same. If one has an entire career's worth of source code and data files written on unix systems with case-sensitive filesystems, it makes things much easier to have a compatible filesystem to see these files on MacOS.
Thanks Flat Five.
I'd love one, but, "By the Guardians" I'd spend way too much time holding a ring to it and chanting the oath.
Even though Apple didn't really embrace it, I was thrilled when Apple joined the rest of the world and at least made a case-sensitive file system option available.
I don't like case insensitivity at all - too many things break when dealing with other systems.
Modern file systems should be case sensitive, not trap you the way older, less sophisticated file systems did.
Just to make sure, are you saying that when osx is the only os using case insensitive, but preserving file system by default, the rest of the world should change to the same and not the other way?
When the reality isn't compatible with Apple, it's reality's fault?
Case-preserving is by far the most common, and more user-friendly.
No, I'm saying all OSs should be case sensitive at all times.
"foo.c" should never, ever be the same as "FOO.C", "foo.C" or any other variant.
One of my pet peeves about Apple's file system.
You shouldn't need to add a file extension. That information should be part of the file metadata.
...extensions can be useful when looking at lists of filenames, but I agree that extensions should not have semantic significance.
My personnal philosophy is that filename, like variable, should be significative and describe what it does. But that just me, I'm weird that way
You "shouldn't" but it makes a lot of sense when looking at a text-based directory of files to know what's source code, what's a header file and what's an executable.
Download most any GNU software package and imagine the contents with all the dot suffixes stripped; not pretty.
That's exactly my comment - humans may find the extensions useful, but the computer should know that a file is C++ source whether it has an extension of ".c", ".C", ".cpp", ".c++", ".so" or ".exe".
Nothing that the computer software does should be based solely on the character patterns in the filenames.
Most any GNU software package is pretty ugly regardless.
I like GNU's layout a lot better than the complete mess that is generated with an XCode project.
Regardless, it's largely a religious argument; either way IMHO the filesystem should always know that A is different from a and should act accordingly. File naming is largely a convention, but conventions exist for a reason, to make life easier for the human trying to find something. If the system alone knew whether "foo" was C text or C++ text, that would mean I'd have to jump through extra hoops to find out.
It works for most other OSs and is only an issue with OS X because some commercial software still doesn't agree with itself on the case of the filenames it creates for itself.