6 ms·

Will they deploy it case insensitive, still?

• entee 10y ago
  Presumably as with today, you'll have the option. I don't have a strong opinion on case sensitivity of file names, but I suspect they'll keep it case insensitive by default. I think for the average non-technical user that two files, "MyFile.txt" and "myfile.txt", being different could lead to some confusion, and Apple historically has apparently considered that confusion unacceptable.
  • crucialfelix 10y ago
    More problematic is that many case insensitive hard drives would be copied into new machines and there would be millions of conflicts. Some utility would have to sit there and annoy people by asking them to make decisions.
    • bjt 10y ago
      I can see why there would be conflicts going case sensitive -> case insensitive, but I can't see why there would be conflicts going the other way. Am I missing something?
      • imglorp 10y ago
        I think you have it backwards. If you try to expand an archive with FOO.TXT and foo.txt, what should happen if you're writing to a case insensitive file system? $ touch HI $ touch hi $ ls HI So that's disturbing. Another problem is every software you can think of will be comparing two files case insensitively. Almost weekly I get burned by this. $ touch HI $ test -f hi && echo ok ok
        • bjt 10y ago
          That's not convincing me that I have it backwards. I was responding to this point in the parent comment: > many case insensitive hard drives would be copied into new machines and there would be millions of conflicts I still don't see where you get a conflict copying the contents of a case-insensitive file system to a case-sensitive one.
          • cynix 10y ago
            > I still don't see where you get a conflict copying the contents of a case-insensitive file system to a case-sensitive one. Because some apps create MyFile.txt and expect to be able to access it later by myfile.txt. Adobe's applications, for example.
            • bjt 10y ago
              I had no idea. That's horrifying.
              • colejohnson66 10y ago
                Open up the various folders of Adobe's software (on Windows). The DLLs are a mish-mash of all lowercase and upper-lower mixes. Heck, open up System32; the DLLs there are definitely not case-sensitive capable (`kbd*.dll' being one example). In fact, I bet you there's at least one program on your computer that accesses the Program Files using `C:\PROGRAM FILES (X86)' instead of `%programfiles(x86)%'. In fact, even environment variables aren't case-sensitive.
      • lewisl9029 10y ago
        I think the parent meant the other way around too. However, the transition between the case insensitive and case sensitive filesystems isn't going to happen overnight. People will be copying files around both ways for quite some time, so the insensitive -> sensitive case is still going to be a concern.
      • Retra 10y ago
        If you have a file named "MyFile.txt" and another system is looking for "myfile.txt", then it'll not be found and Apple will not let you rename it because it thinks it's a no-op. That's frustrating as hell.
        • ridiculous_fish 10y ago
          Apple's software (Finder, mv) lets you rename these. But it's true that some tools (I think git) get confused here.
          • davidwtbuxton 10y ago
            Git init / clone on case-insensitive HFS+ sets `git config core.ignorecase true`, which can lead to confusing behaviour where it ignores a change in the case of a filename. > The default is false, except git-clone(1) or git-init(1) will probe and set core.ignoreCase true if appropriate when the repository is created. https://www.kernel.org/pub/software/scm/git/docs/git-config.html https://www.kernel.org/pub/software/scm/git/docs/git-config....
  • cuddlybacon 10y ago
    Steam relies on the filesystem being insensitive.
    • wtetzner 10y ago
      Really? What filesystem do they use in SteamOS?
      • mbilker 10y ago
        SteamOS is Linux, based on Ubuntu. So I assume it is ext4, ext3, or xfs. Btrfs is not stable enough IMO for something like SteamOS.
        • gh02t 10y ago
          SteamOS is based on an older Debian release and uses ext4.
    • bluedino 10y ago
      Does Adobe still?
      • cynix 10y ago
        Yes they do.
    • majewsky 10y ago
      No it doesn't. How would it work on Linux if it did?
      • lake99 10y ago
        Both, you and cuddlybacon are right. A long time ago, they worked under the assumption that the FS is case-sensitive, and all the games I installed back then had title-cased folder names. Gradually, Valve stopped caring about this, and my games stopped working. I had to go in and manually change some game folder names to lower-case. It then kept some small files under SteamApps and the downloaded games under steamapps. They have fixed that now. Now, I have both CONFIG and config in my Steam folder. How would it work? By a combination of magic and "we can't be bothered; the users should figure out something".
  • speleding 10y ago
    For the end-user they could prevent duplicate different-cased file names in the UI layer (the Finder), instead of the file system. That would be a more appropriate place for it anyway.
    • wmf 10y ago
      And then some code using Unix APIs would create two files whose names differ only in case and the UI layer would choke. This is why spray-on usability is bad.
      • speleding 10y ago
        The UI already has to deal with that anyway because it supports case sensitive volumes. What exactly constitutes case is locale specific, it differs from one user to the next, that logic would be messy to have inside the file system.
    • entee 10y ago
      That would likely be a hassle because you'd have to be consistent for all programs that ever save or read a file. As a result it has to be an OS-level thing at least, if not at the file system level. I don't have a huge preference (case sensitive or insensitive), I think it's not worth a religious war, but whatever the choice is, it should be completely transparent to understand what convention the system is using as a coder, and as a general user.
    • _pmf_ 10y ago
      This is a horrible solution.
  • mikeash 10y ago
    The average user is also confused by "MyFile.txt" and " MyFile.txt" being different, or "Proposal II" and "Proposal 2" being different, but filesystems aren't usually built around that. I don't think case sensitivity is special enough to get that sort of treatment.
  • spott 10y ago
    I believe the problem is also present for a large amount of third party software, making the move to case sensitive drives pretty hard to do: [0] https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html https://helpx.adobe.com/creative-suite/kb/error-case-sensiti... [1] http://apple.stackexchange.com/questions/192185/os-x-case-sensitive-issues http://apple.stackexchange.com/questions/192185/os-x-case-se... [2] http://dcatteeu.github.io/article/2015/12/31/case-sensitive-filesystem/ http://dcatteeu.github.io/article/2015/12/31/case-sensitive-...
    • dhagz 10y ago
      I've noticed some bugs with case-sensitivity recently in Ruby, of all things.
  • spott 10y ago
    I believe the problem is also present for a large amount of third party software, making the move to case sensitive drives pretty hard to do: [0] https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html https://helpx.adobe.com/creative-suite/kb/error-case-sensiti... [1] http://apple.stackexchange.com/questions/192185/os-x-case-sensitive-issues http://apple.stackexchange.com/questions/192185/os-x-case-se... [2] http://dcatteeu.github.io/article/2015/12/31/case-sensitive-filesystem/ http://dcatteeu.github.io/article/2015/12/31/case-sensitive-...
  • cmurf 10y ago
    The fs should be case sensitive. If they want to enforce insensitivity it should be done with APIs for programs including the Finder.
• 1amzave 10y ago
  According to their documented "Current Limitations" (https://developer.apple.com/library/prerelease/content/documentation/FileManagement/Conceptual/APFS_Guide/UsingtheAppleFileSystem/UsingtheAppleFileSystem.html#//apple_ref/doc/uid/TP40016999-CH4-DontLinkElementID_24 https://developer.apple.com/library/prerelease/content/docum...): > Case Sensitivity: Filenames are currently case-sensitive only. First thought: they have seen the light! A moment later: wait...they consider this a "limitation", and it's only "currently" the case. So maybe they're going to perpetuate the brain-damage anyway. Sigh.
  • chungy 10y ago
    Just as with HFS+ and ZFS, case-insensitivity will be an option.
  • msbarnett 10y ago
    There's plenty of code in the wild that assumes case-insensitivity since that's been the case since forever. Backwards compatibility is going to end up trumping whatever ideological purity case sensitivity represents.
  • spullara 10y ago
    Ok, what is the argument against case preserving but insensitive file systems?
    • KMag 10y ago
      It pushes a localization and UI problem down into the filesystem layer. Case-insensitivity is pretty easy for US-ASCII, but in release 2 of your filesystem, you realized you didn't properly handle LATIN WIDE characters, the Cyrillic alphabet, etc. In release 7 of your FS, you get case sensitivity correct for Klingon, but some popular video game relied on everything except Klingon being case-insensitive on your FS, and now all of the users are complaining. How do you handle the case where the only difference between two file names is that one uses Latin wide characters and the other uses Latin characters? This one bit me when writing a CAPTCHA system back in 2004. (Long story, but existing systems wouldn't work between a credit card processing server that had to validate in Perl, and a web form that had to be written in PHP, where the two systems couldn't share a file system. It's simple enough to do using HMAC and a shared key between the two servers, but for some reason, none of the available solutions did it.) I noticed that Japanese users had a disturbingly high CAPTCHA failure rate. It turns out that many East Asian languages have characters that are roughly square, and most Latin characters are roughly half as wide as they are tall, so mixing the two looks odd. So, Unicode has a whole set of Latin wide characters that are the same as the Latin characters we use in English, except they're roughly square, so they look better when mixed with Unified Han and other characters. Apparently most Japanese web browsers (or maybe it's an OS level keyboard layout setting) will by default emit Latin wide unicode code points when the user types Latin characters. Whether or not to normalize wide Latin characters to Latin characters is a highly context-dependent choice. In my case, it was definitely necessary, but in other cases it will throw out necessary information and make documents look ugly/odd. Good arguments can be made both ways about how a case-insensitive filesystem should handle Latin wide characters, and that's a relatively simple case. Most users don't type names of existing files, exclusively accessing files through menus, file pickers, and the OS's graphical command shell (Finder/Explorer). So, if you want to avoid users getting confused over similar file names, that can be handled at file creation time (as well as more subtle issues that are actually more likely to confuse users, such as file names that have two consecutive spaces, etc., etc.) via UI improvements.