20 ms·

Linus Torvalds: Apple's HFS+ is probably the worst file-system ever

97 points by arnieswap 12y ago

duaneb 12y ago
This is just Linux grumping about subjective tastes—he rags on the default case sensitivity of HFS+ and the finder, neither of which he's forced to use even if he's stapled to a mac. If you want a case sensitive filesystem, reformat your damn mac! I've seen it confuse enough non-computer savvy people I wouldn't want Apple to change their filesystem for the sake of developers who need to distinguish between headers by case. NB: I use a case-sensitive HFS+ install for cross-compiling when it's necessary.
- cremno 12y ago
  What about normalization, which by the way, isn't actually NFD — it's just very similar to it?
- outworlder 12y ago
  Don't underestimate the power of defaults. Also, this can trip up in several other contexts besides headers. For instance, someone renames a file in their repository, changing just a filename case. And then you'll have to scratch your head a bit to understand a git issue that will invariably arise when you pull in the changes. Unless you are fortunate enough not to have a deadline, you won't be so quick to reformat the machine. This actually happened to me. In the end, it was quicker to spin up a linux vm than to reformat the machine. EDIT: Also, you appear to have missed the part that says "There is a case sensitive option, but Apple actively hides it and doesn't support it." No support is really, really, really bad. Noone will deploy OSX machines formatted like that if it is unsupported.
  - duaneb 12y ago
    I'm not saying reformat the machine, I'm saying don't depend on case sensitivity if you use a default configured mac. And if you do depend on it, don't use the default configuration of the mac. How hard is this to figure out? It's not like case sensitivity is inherently desirable or better, especially for source code, where I would argue it's actively confusing and a huge code smell.
  - tambourine_man 12y ago
    OS X is primarily a consumer's OS. Every time a decision has to be made between making the life of the programer or the consumer easier, Apple will choose the latter.
    - walterbell 12y ago
      On iOS, Apple made a consumer-unfriendly change when they disabled virtual printing, e.g. local Print-to-PDF from any application to a virtual-printer app.
- molf 12y ago
  Except that a case-sensitive HFS+ file system breaks tons of Mac apps that are never tested with it.
  - wlesieutre 12y ago
    A few examples: - Creative Suite http://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html http://helpx.adobe.com/creative-suite/kb/error-case-sensitiv... - Steam https://support.steampowered.com/kb_article.php?ref=8601-RYPX-5789 https://support.steampowered.com/kb_article.php?ref=8601-RYP... - Unity http://forum.unity3d.com/threads/fatal-error-case-sensitive-file-system.116968/ http://forum.unity3d.com/threads/fatal-error-case-sensitive-... Mac apps not running on case sensitive filesystems is probably more common than not.
  - duaneb 12y ago
    Well, most users are not developers and will not need to use a case sensitive filesystem.
- saosebastiao 12y ago
  As the primary author of the most widely used cross platform VCS, he does have to use OSX.
  - duaneb 12y ago
    > As the primary author of the most widely used cross platform VCS, he does have to use OSX. Sure, but he doesn't need to bitch about things just to bitch about things... it's not like case sensitivity is a problem for anything but poorly designed build systems.
- shanemhansen 12y ago
  I think you mean Linus, not Linux. While tastes are certainly subjective, the exploit caused by this brain damaged design was not subjective, nor a matter of taste.
  - pionar 12y ago
    The exploit was not "caused" by HFS+. It was caused by either not knowing or not caring that HFS is a case-insensitive file system.
    - duaneb 12y ago
      > that HFS is a case-insensitive file system. ...by default.
  - duaneb 12y ago
    It's subjective. HFS+ is perfectly capable of being case-sensitive if necessary, so it's not a fault of the filesystem. He's just griping about the default configuration of developer machines. News flash: if you're a developer, you may have to think about how your computer is configured. You might as well complain how some linux distros don't come with emacs installed and calling it 'brain damaged design' because it isn't what you want.
cremno 12y ago
Another “funny” detail: >The maximum representable date is February 6, 2040 at 06:28:15 GMT. http://dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html http://dubeiko.com/development/FileSystems/HFSPLUS/tn1150.ht...
- stygiansonic 12y ago
  Interesting: I didn't realize the "Epoch" in this case was "midnight, January 1, 1904, GMT". Given that the representation is stored as an unsigned 32-bit integer, it seems like you cannot represent dates older than this "Epoch" starting value. Since it's a file system, that's probably of much less concern than a more general date-time format. However, does anyone know the genesis behind which this particular date was chosen? It's far enough back to not cause any issues and appears to be close to the minimum date-time value obtained using the minimum value for signed 32-bit integer and the standard Unix Epoch (which would be around 13 Dec 1901), but other than that?
  - pjc50 12y ago
    https://support.microsoft.com/kb/180162?wa=wsignin1.0 https://support.microsoft.com/kb/180162?wa=wsignin1.0 The 1900 epoch needs additional code to handle the fact that 1900 was not a leap year. Why not the UNIX epoch? Well that's another question entirely.
    - Someone 12y ago
      Also: http://support.microsoft.com/kb/214326 http://support.microsoft.com/kb/214326: "Explains why the year 1900 is treated as a leap year in Excel 2000" Mac OS was written in a time of memory scarcity; 1904 is just an easier choice for the epoch than 1900. That's also why they didn't choose the Unix epoch, as it would have required supporting multiple epochs, one for disk time stamps, and one to handle birth dates (time stamps on classic Mac OS are unsigned; there were no times before the epoch. And yes, there were no Mac users over 80 :-))
kaolinite 12y ago
There are very real problems with HFS+ related to reliability and data corruption. It really is quite bad. Linus's argument is silly, however, and purely a matter of taste. Case insensitivity certainly isn't the reason that HFS+ is bad.
- jiggy2011 12y ago
  I don't even understand why he doesn't like case insensitivity. I can't think of a reason to have two files with the same name that vary only in capitalisation.
  - thirsteh 12y ago
    I guess his complaint is that lower(str) == lower(ostr) is more code than str == ostr...? :)
    - userbinator 12y ago
      A lot more code, if you count the fact that the definition of "case" varies between languages, some of which don't even have such a concept. Add to that Unicode's varying representations that are visually identical but different sequences of bytes, and you have one hell of morass to deal with.
      - thirsteh 12y ago
        But that's a pretty silly complaint if that's really his argument. Nobody except kernel devs cares if the kernel needs to do case folding when it's 98% a UX issue.
        tankenmate 12y ago
        All users care once it, personally, impacts their performance and their security.
  - Afforess 12y ago
tambourine_man 12y ago
What a shitty article. HFS+ has many problems, but case insensitivity is a feature. It's good for end users. There's a case sensitive version of it, but it's not the default, and for a good reason. If you want a good critique of HFS+, check one of John Siracusa's many rants[1]. Also, Gruber is not the author of Byword: Even John Gruber of Daring Fireball and author of Byword… [1] http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/ http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/
- gondo 12y ago
  what a shitty comment. did you try to use some Adobe product on case sensitive version of HFS+? let me guess, no you didn't. because if you would, you would find out that some programs simply doesnt work on case sensitive HFS+, most likely because people like you, who simply "know" whats better for end user
  - durin42 12y ago
    It's almost certainly a bug in a build script somewhere, and they're dynamically linking against something via the wrong name. I once linked against Quicktime.framework, and it worked on everything but my case-sensitive Mac. QuickTime.framework worked everywhere. So your Adobe example is flawed. They should be testing on case-sensitive volumes, but the vast majority of normal users don't want a file named README and readme in the same directory, and enforcing that invariant seems reasonable to me.
  - tambourine_man 12y ago
    It is a bad article. The author uses a quote from 2002 to criticize the Finder, in order to support his claim that today's Apple software is bad in general, and therefore HFS+ sucks. Which it does indeed, pretty badly. You would be hard pressed to find a worse FS still in use, excluding FAT, which will just never die. Except the article doesn't contribute to the discussion and the quotes from Linus are unfortunately not newsworthy. Instead of a deep critique, perhaps pointing what it should learn from Btrfs and ZFS, he acuses Apple of not shipping a consumer case sensitive FS and criticizes its string and slash encoding, which although bad, are successfully abstracted even from most developers. It then ends stating that Apple, like the weather, pays no attention to criticism. As empty an analysis as can be.
api 12y ago
HFS+ and NTFS both suck pretty hard. There seems to be some kind of pessimism filesystem principle in popular mainstream OSes. It's kind of impressive that Apple and MS have managed to make such balls of crap work as well as they have.
jansanchez 12y ago
Yesterday's discussion: https://news.ycombinator.com/item?id=8876319 https://news.ycombinator.com/item?id=8876319
babl-yc 12y ago
As a developer I could see case-sensitive file systems as more "proper" and predictable. But as an everyday Mac user, I'd be annoyed if I accidentally selected "upload.png" instead of "Upload.png" and sent the wrong file.
- Shivetya 12y ago
  just as with programming languages, case sensitivity seems to me to purposefully introducing the possibility of errors.
- userbinator 12y ago
  But as an everyday Mac user, I'd be annoyed if I accidentally selected "upload.png" instead of "Upload.png" and sent the wrong file. That assumes you somehow created two files with names differing only in case, which I'd argue would happen only if you were naming your files with such generic names. Also, I don't think the fact that two files' names look similar should be any reason to treat them as the same - otherwise, would you suggest that the letter O and the number 0 (along with the letter o) should be considered identical for filenames?
  - FreezerburnV 12y ago
    You obviously don't understand how a lot of people actually use their computer: http://xkcd.com/1459/ http://xkcd.com/1459/ (please note the tongue firmly planted in cheek, even if a lot of people actually DO work like this. which is terrifying)
kevingadd 12y ago
For reference, NTFS is case-sensitive. Win32 is case-insensitive. The case sensitivity is implemented at a layer above the filesystem so that classic Windows apps will behave the way users expect. (Case sensitive filesystems are confusing for users and mostly create opportunities for horrible mishaps.) As a result, the POSIX subsystem can store case sensitive files just like a linux FS would, with 'FOO' and 'foo' being separate files right next to each other: http://support.microsoft.com/kb/100625 http://support.microsoft.com/kb/100625 Case insensitivity like win32's is still kind of a mess, but it's unfair to paint the developers of NTFS as idiots when they actually got this right. Above the FS layer is the correct place to implement case insensitivity, because case insensitivity is a feature that aids users in selecting files, not a feature that aids applications in opening them or creating them.
- durin42 12y ago
  I don't know. Now you end up in a circumstance where you have N files named some variant of "Foo" and the GUI layer can't distinguish them. Enforcing this invariant at the filesystem layer (with well defined semantics, which HFS+ at least documents semi-well) seems eminently reasonable to me.
ZoFreX 12y ago
Really? The developer who wrote software for Windows and OS X that depends on a case-sensitive file-system is going to throw stones about bad software? Windows and OS X use case-sensitive file-systems. That sucks. But if you are going to release software for those systems, you need to accept that that is the reality, and write your software accordingly. This is hardly the first issue Git has had due to this, Linus's time would be better spent fixing these issues rather than stamping his feet and expecting OS X and Windows to change.
- Morgawr 12y ago
  I think you mean case-insensitive filesystems.
- fulafel 12y ago
  Linus didn't write or port git for Windows or OS X. In fact for the longest time git on Windows required Cygwin. I doubt Linus was even much involved in git maintenance by the time native Windows support was merged... or was it ever? Is msysgit a fork?
mproud 12y ago
Another misleading headline, simply for linkbait and dollars.
forgottenpass 12y ago
This is just blogspam of something that was popular on social media yesterday. Which is where Linux Veda found it in the first place and proceeded to not add any meaningful commentary or context. It was already discussed to death here: https://news.ycombinator.com/item?id=8876319 https://news.ycombinator.com/item?id=8876319
- deleted 12y ago
  [deleted]
archagon 12y ago
Technical hurdles aside, I just can't agree that case-sensitivity makes sense. To most people, an "a" and an "A" are not different symbols; they're the same letter with "uppercase" formatting applied, much like bold or italics. And although one could argue that you could make a case-insensitive GUI layer while keeping the implementation case-sensitive, I feel that the terminal can be just as important from a UX perspective as anything else in the OS. After all, it's one of the main places power users create and access files. Given how much Siracusa and Torvalds (to an extent) advocate for better user experience over ease of technical implementation, I feel I'm missing something. Our job as programmers is to encompass the complexity of the real world in our programs, not to make our users think like machines.
- dragonwriter 12y ago
  > To most people, an "a" and an "A" are not different symbols; they're the same letter with "uppercase" formatting applied, much like bold or italics. So, what you are saying, is that there is no semantic difference between "1 mm" and "1 Mm"? Or between "my next computer" and "my NeXT computer"? Or between "acorn" and "ACORN"?
- ominous 12y ago
  tO MOST PEOPLE?
- forgottenpass 12y ago
  not to make our users think like machines. If differentiating between "file" and "File" is thinking like a machine, how isn't differentiating between "my files" and "myfiles" thinking like a machine? Should "my files" and "myfiles" be collapsed to mean the same thing? What about "files"?
  - ominous 12y ago
    or "tus ficheros"
  - archagon 12y ago
    An "f" is not a different character from an "F". To most people, it's the same letter with special formatting applied. They don't see it and think, "Oh, that's ASCII character 102." An F is an f, no matter how you type it. On the other hand, "myfiles" and "my files" have different numbers of characters. They sound different in your head, and you can easily point to the difference. It's the same as typing "alien" versus "a lien".
haberman 12y ago
I seem to remember a story of how this decision was made (or at least a part of it). I thought I remembered hearing that Steve Jobs was in a roomful of developers and took a quick poll of whether they liked case sensitive vs case-preserving filesystems, and case-preserving won. I could be totally making this up though. Anyone remember hearing this and can confirm?
AshFurrow 12y ago
I wonder how much Adobe's incompatibility with case-sensitive filesystems affected Apple's decisions: https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html https://helpx.adobe.com/creative-suite/kb/error-case-sensiti...
sigsergv 12y ago
He's absolutely right about NFD, it's horrible. If you're using plain latin-1 you usually don't have any problems. And everything changes if you are using “composite” characters like à or ё or й. It's not just HFS+ issue, it's a system-wide issue, that break mounted network resources for example. Or even USB sticks.
mproud 12y ago
Focusing on the non-technical details… case-sensitive filesystems just seems horrible for consumers! At my day job, I work with people who have barely used a computer before. I could see an 80-year old woman having three versions of a letter she typed in Pages or Word, simply because she had mixed use capital letters, and then mistakening the versions and deleting the wrong file.

97 points by arnieswap 12y ago

This is just Linux grumping about subjective tastes—he rags on the default case sensitivity of HFS+ and the finder, neither of which he's forced to use even if he's stapled to a mac. If you want a case sensitive filesystem, reformat your damn mac! I've seen it confuse enough non-computer savvy people I wouldn't want Apple to change their filesystem for the sake of developers who need to distinguish between headers by case. NB: I use a case-sensitive HFS+ install for cross-compiling when it's necessary.

cremno 12y ago
What about normalization, which by the way, isn't actually NFD — it's just very similar to it?
outworlder 12y ago
Don't underestimate the power of defaults. Also, this can trip up in several other contexts besides headers. For instance, someone renames a file in their repository, changing just a filename case. And then you'll have to scratch your head a bit to understand a git issue that will invariably arise when you pull in the changes. Unless you are fortunate enough not to have a deadline, you won't be so quick to reformat the machine. This actually happened to me. In the end, it was quicker to spin up a linux vm than to reformat the machine. EDIT: Also, you appear to have missed the part that says "There is a case sensitive option, but Apple actively hides it and doesn't support it." No support is really, really, really bad. Noone will deploy OSX machines formatted like that if it is unsupported.
- duaneb 12y ago
  I'm not saying reformat the machine, I'm saying don't depend on case sensitivity if you use a default configured mac. And if you do depend on it, don't use the default configuration of the mac. How hard is this to figure out? It's not like case sensitivity is inherently desirable or better, especially for source code, where I would argue it's actively confusing and a huge code smell.
- tambourine_man 12y ago
  OS X is primarily a consumer's OS. Every time a decision has to be made between making the life of the programer or the consumer easier, Apple will choose the latter.
  - walterbell 12y ago
    On iOS, Apple made a consumer-unfriendly change when they disabled virtual printing, e.g. local Print-to-PDF from any application to a virtual-printer app.
molf 12y ago
Except that a case-sensitive HFS+ file system breaks tons of Mac apps that are never tested with it.
- wlesieutre 12y ago
  A few examples: - Creative Suite http://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html http://helpx.adobe.com/creative-suite/kb/error-case-sensitiv... - Steam https://support.steampowered.com/kb_article.php?ref=8601-RYPX-5789 https://support.steampowered.com/kb_article.php?ref=8601-RYP... - Unity http://forum.unity3d.com/threads/fatal-error-case-sensitive-file-system.116968/ http://forum.unity3d.com/threads/fatal-error-case-sensitive-... Mac apps not running on case sensitive filesystems is probably more common than not.
- duaneb 12y ago
  Well, most users are not developers and will not need to use a case sensitive filesystem.
saosebastiao 12y ago
As the primary author of the most widely used cross platform VCS, he does have to use OSX.
- duaneb 12y ago
  > As the primary author of the most widely used cross platform VCS, he does have to use OSX. Sure, but he doesn't need to bitch about things just to bitch about things... it's not like case sensitivity is a problem for anything but poorly designed build systems.
shanemhansen 12y ago
I think you mean Linus, not Linux. While tastes are certainly subjective, the exploit caused by this brain damaged design was not subjective, nor a matter of taste.
- pionar 12y ago
  The exploit was not "caused" by HFS+. It was caused by either not knowing or not caring that HFS is a case-insensitive file system.
  - duaneb 12y ago
    > that HFS is a case-insensitive file system. ...by default.
- duaneb 12y ago
  It's subjective. HFS+ is perfectly capable of being case-sensitive if necessary, so it's not a fault of the filesystem. He's just griping about the default configuration of developer machines. News flash: if you're a developer, you may have to think about how your computer is configured. You might as well complain how some linux distros don't come with emacs installed and calling it 'brain damaged design' because it isn't what you want.

cremno 12y ago

Another “funny” detail: >The maximum representable date is February 6, 2040 at 06:28:15 GMT. http://dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html http://dubeiko.com/development/FileSystems/HFSPLUS/tn1150.ht...

stygiansonic 12y ago
Interesting: I didn't realize the "Epoch" in this case was "midnight, January 1, 1904, GMT". Given that the representation is stored as an unsigned 32-bit integer, it seems like you cannot represent dates older than this "Epoch" starting value. Since it's a file system, that's probably of much less concern than a more general date-time format. However, does anyone know the genesis behind which this particular date was chosen? It's far enough back to not cause any issues and appears to be close to the minimum date-time value obtained using the minimum value for signed 32-bit integer and the standard Unix Epoch (which would be around 13 Dec 1901), but other than that?
- pjc50 12y ago
  https://support.microsoft.com/kb/180162?wa=wsignin1.0 https://support.microsoft.com/kb/180162?wa=wsignin1.0 The 1900 epoch needs additional code to handle the fact that 1900 was not a leap year. Why not the UNIX epoch? Well that's another question entirely.
  - Someone 12y ago
    Also: http://support.microsoft.com/kb/214326 http://support.microsoft.com/kb/214326: "Explains why the year 1900 is treated as a leap year in Excel 2000" Mac OS was written in a time of memory scarcity; 1904 is just an easier choice for the epoch than 1900. That's also why they didn't choose the Unix epoch, as it would have required supporting multiple epochs, one for disk time stamps, and one to handle birth dates (time stamps on classic Mac OS are unsigned; there were no times before the epoch. And yes, there were no Mac users over 80 :-))

kaolinite 12y ago

There are very real problems with HFS+ related to reliability and data corruption. It really is quite bad. Linus's argument is silly, however, and purely a matter of taste. Case insensitivity certainly isn't the reason that HFS+ is bad.

jiggy2011 12y ago
I don't even understand why he doesn't like case insensitivity. I can't think of a reason to have two files with the same name that vary only in capitalisation.
- thirsteh 12y ago
  I guess his complaint is that lower(str) == lower(ostr) is more code than str == ostr...? :)
  - userbinator 12y ago
    A lot more code, if you count the fact that the definition of "case" varies between languages, some of which don't even have such a concept. Add to that Unicode's varying representations that are visually identical but different sequences of bytes, and you have one hell of morass to deal with.
    - thirsteh 12y ago
      But that's a pretty silly complaint if that's really his argument. Nobody except kernel devs cares if the kernel needs to do case folding when it's 98% a UX issue.
      - tankenmate 12y ago
        All users care once it, personally, impacts their performance and their security.
- Afforess 12y ago

tambourine_man 12y ago

What a shitty article. HFS+ has many problems, but case insensitivity is a feature. It's good for end users. There's a case sensitive version of it, but it's not the default, and for a good reason. If you want a good critique of HFS+, check one of John Siracusa's many rants[1]. Also, Gruber is not the author of Byword: Even John Gruber of Daring Fireball and author of Byword… [1] http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/ http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/

gondo 12y ago
what a shitty comment. did you try to use some Adobe product on case sensitive version of HFS+? let me guess, no you didn't. because if you would, you would find out that some programs simply doesnt work on case sensitive HFS+, most likely because people like you, who simply "know" whats better for end user
- durin42 12y ago
  It's almost certainly a bug in a build script somewhere, and they're dynamically linking against something via the wrong name. I once linked against Quicktime.framework, and it worked on everything but my case-sensitive Mac. QuickTime.framework worked everywhere. So your Adobe example is flawed. They should be testing on case-sensitive volumes, but the vast majority of normal users don't want a file named README and readme in the same directory, and enforcing that invariant seems reasonable to me.
- tambourine_man 12y ago
  It is a bad article. The author uses a quote from 2002 to criticize the Finder, in order to support his claim that today's Apple software is bad in general, and therefore HFS+ sucks. Which it does indeed, pretty badly. You would be hard pressed to find a worse FS still in use, excluding FAT, which will just never die. Except the article doesn't contribute to the discussion and the quotes from Linus are unfortunately not newsworthy. Instead of a deep critique, perhaps pointing what it should learn from Btrfs and ZFS, he acuses Apple of not shipping a consumer case sensitive FS and criticizes its string and slash encoding, which although bad, are successfully abstracted even from most developers. It then ends stating that Apple, like the weather, pays no attention to criticism. As empty an analysis as can be.

api 12y ago

HFS+ and NTFS both suck pretty hard. There seems to be some kind of pessimism filesystem principle in popular mainstream OSes. It's kind of impressive that Apple and MS have managed to make such balls of crap work as well as they have.

jansanchez 12y ago

Yesterday's discussion: https://news.ycombinator.com/item?id=8876319 https://news.ycombinator.com/item?id=8876319

babl-yc 12y ago

As a developer I could see case-sensitive file systems as more "proper" and predictable. But as an everyday Mac user, I'd be annoyed if I accidentally selected "upload.png" instead of "Upload.png" and sent the wrong file.

Shivetya 12y ago
just as with programming languages, case sensitivity seems to me to purposefully introducing the possibility of errors.
userbinator 12y ago
But as an everyday Mac user, I'd be annoyed if I accidentally selected "upload.png" instead of "Upload.png" and sent the wrong file. That assumes you somehow created two files with names differing only in case, which I'd argue would happen only if you were naming your files with such generic names. Also, I don't think the fact that two files' names look similar should be any reason to treat them as the same - otherwise, would you suggest that the letter O and the number 0 (along with the letter o) should be considered identical for filenames?
- FreezerburnV 12y ago
  You obviously don't understand how a lot of people actually use their computer: http://xkcd.com/1459/ http://xkcd.com/1459/ (please note the tongue firmly planted in cheek, even if a lot of people actually DO work like this. which is terrifying)

kevingadd 12y ago

For reference, NTFS is case-sensitive. Win32 is case-insensitive. The case sensitivity is implemented at a layer above the filesystem so that classic Windows apps will behave the way users expect. (Case sensitive filesystems are confusing for users and mostly create opportunities for horrible mishaps.) As a result, the POSIX subsystem can store case sensitive files just like a linux FS would, with 'FOO' and 'foo' being separate files right next to each other: http://support.microsoft.com/kb/100625 http://support.microsoft.com/kb/100625 Case insensitivity like win32's is still kind of a mess, but it's unfair to paint the developers of NTFS as idiots when they actually got this right. Above the FS layer is the correct place to implement case insensitivity, because case insensitivity is a feature that aids users in selecting files, not a feature that aids applications in opening them or creating them.

durin42 12y ago
I don't know. Now you end up in a circumstance where you have N files named some variant of "Foo" and the GUI layer can't distinguish them. Enforcing this invariant at the filesystem layer (with well defined semantics, which HFS+ at least documents semi-well) seems eminently reasonable to me.

ZoFreX 12y ago

Really? The developer who wrote software for Windows and OS X that depends on a case-sensitive file-system is going to throw stones about bad software? Windows and OS X use case-sensitive file-systems. That sucks. But if you are going to release software for those systems, you need to accept that that is the reality, and write your software accordingly. This is hardly the first issue Git has had due to this, Linus's time would be better spent fixing these issues rather than stamping his feet and expecting OS X and Windows to change.

Morgawr 12y ago
I think you mean case-insensitive filesystems.
fulafel 12y ago
Linus didn't write or port git for Windows or OS X. In fact for the longest time git on Windows required Cygwin. I doubt Linus was even much involved in git maintenance by the time native Windows support was merged... or was it ever? Is msysgit a fork?

mproud 12y ago

Another misleading headline, simply for linkbait and dollars.

forgottenpass 12y ago

This is just blogspam of something that was popular on social media yesterday. Which is where Linux Veda found it in the first place and proceeded to not add any meaningful commentary or context. It was already discussed to death here: https://news.ycombinator.com/item?id=8876319 https://news.ycombinator.com/item?id=8876319

deleted 12y ago
[deleted]

archagon 12y ago

Technical hurdles aside, I just can't agree that case-sensitivity makes sense. To most people, an "a" and an "A" are not different symbols; they're the same letter with "uppercase" formatting applied, much like bold or italics. And although one could argue that you could make a case-insensitive GUI layer while keeping the implementation case-sensitive, I feel that the terminal can be just as important from a UX perspective as anything else in the OS. After all, it's one of the main places power users create and access files. Given how much Siracusa and Torvalds (to an extent) advocate for better user experience over ease of technical implementation, I feel I'm missing something. Our job as programmers is to encompass the complexity of the real world in our programs, not to make our users think like machines.

dragonwriter 12y ago
> To most people, an "a" and an "A" are not different symbols; they're the same letter with "uppercase" formatting applied, much like bold or italics. So, what you are saying, is that there is no semantic difference between "1 mm" and "1 Mm"? Or between "my next computer" and "my NeXT computer"? Or between "acorn" and "ACORN"?
ominous 12y ago
tO MOST PEOPLE?
forgottenpass 12y ago
not to make our users think like machines. If differentiating between "file" and "File" is thinking like a machine, how isn't differentiating between "my files" and "myfiles" thinking like a machine? Should "my files" and "myfiles" be collapsed to mean the same thing? What about "files"?
- ominous 12y ago
  or "tus ficheros"
- archagon 12y ago
  An "f" is not a different character from an "F". To most people, it's the same letter with special formatting applied. They don't see it and think, "Oh, that's ASCII character 102." An F is an f, no matter how you type it. On the other hand, "myfiles" and "my files" have different numbers of characters. They sound different in your head, and you can easily point to the difference. It's the same as typing "alien" versus "a lien".

haberman 12y ago

I seem to remember a story of how this decision was made (or at least a part of it). I thought I remembered hearing that Steve Jobs was in a roomful of developers and took a quick poll of whether they liked case sensitive vs case-preserving filesystems, and case-preserving won. I could be totally making this up though. Anyone remember hearing this and can confirm?

AshFurrow 12y ago

I wonder how much Adobe's incompatibility with case-sensitive filesystems affected Apple's decisions: https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html https://helpx.adobe.com/creative-suite/kb/error-case-sensiti...

sigsergv 12y ago

He's absolutely right about NFD, it's horrible. If you're using plain latin-1 you usually don't have any problems. And everything changes if you are using “composite” characters like à or ё or й. It's not just HFS+ issue, it's a system-wide issue, that break mounted network resources for example. Or even USB sticks.

mproud 12y ago

Focusing on the non-technical details… case-sensitive filesystems just seems horrible for consumers! At my day job, I work with people who have barely used a computer before. I could see an 80-year old woman having three versions of a letter she typed in Pages or Word, simply because she had mixed use capital letters, and then mistakening the versions and deleting the wrong file.