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.
For APFS, any reason not to use case-sensitivity?
- Thread starter EugW
- Start date
- Sort by reaction score
Some software does not handle case-sensitive filesystems gracefully. For the boot drive, it is probably a good idea to stick with the defaults. I have used case-sensitive filesystems on external drives for years without any problems.
A.
A.
OK, that's good to know. I'll stick with case insensitive for the boot, but may use case sensitive for external drives.
To give an example, you can have database.dat & Database.dat in the same location. If a program cannot handle sensitivity correctly, it could target either & you wouldn't know which until it's executed.
Another possibility is the filesystem only allows one case (I don't know what this file system will do) so you have Database.dat. A program could be written to accept DATABASE.DAT only. If the filesystem is not case sensitive, it doesn't matter how you have the case set. Too much confusion.
In case it helps someone, at some point I upgraded to an APFS (case-sensitive) filesystem and Steam stopped working. So, yeah, Apps might break.
If you are a software development or DevOps professional you may work with production systems that are case sensitive (Linux). You wouldn’t want your software to break in production the way that the aforementioned games are broken on those people’s machines.
I would like to ask the question from the other angle: when is case-sensitive an advantage? I.e., is there any reason *to* use it (rather than is there any reason *not* to use it)?
For the people coming from google: I am currently restoring an external drive with time machine, time machine is by default case sensitive, my drive was not but because time machine is case sensitive I can't restore the drive if it's not case sensitive too 🥲
I dont think so.
I've never formatted any drive to case-sensitive so just checked the TM drives in use to see if TM converted the drives to case-sensitive: it appears not.
So you’ve never set up a new Time Machine since the release of at least Big Sur because if you did you would have seen that selecting a drive to be used as a Time Machine results in it being formatted with an APFS case sensitive volume with no way around that.
I’m not saying that it made sense that I couldn’t copy my stuff back because it doesn’t, hence me being here on the internet talking about that.
Correct.
Well, for older OSes this is not the case.
TBH I find the expression "at least Big Sur" a bit exaggerated. BS is an OS released only a bit more than 1 year ago.
Personally I prefer to use other software for backups e.g. Carbon Copy Cloner instead of Time Machine.
I do use TM though , but just for one specific case .
Last edited:
KeesMacPro, it likely depends on what OS version you are running, hence which version of TM is being used. Because your drives are already formatted and contain TM back-ups, I believe TM will keep working along with them. The default re-formatting by TM I believe occurs when you first select a new drive for TM to back-up to, on an OS newer than Big Sur 11.
For instance, I'm running 10.14 on a MacBookPro early 2013 and TM will back-up to pretty much any format drive I use with it.
However, I popped an empty 3.5" 3TB unused drive I formatted to HFS+ at least 5 years ago into a dock connected to an iMac 27" 2020 running OS 12 Monterey, looking at the specs on that drive now, I see it is formatted APFS (case sensitive). I don't recall reformatting this drive, and I suspect I just don't remember TM telling me it was going to reformat my drive when I first selected it, it was certainly a quick process or I'd remember, this was only a few weeks ago. I suspect TM would have flagged the fact that it was going to delete the contents of that drive if I proceeded... the plot thickens!
Oh wow, that is really good to know!
I can't figure out how to NOT have my fresh backup drive be case-insensitive, encrypted or not. New Machine, New backup drive. Time Machine insists on reformatting it. If I select "encrypted" it makes it "case sensitive, encrypted" if I encrypt it myself, then I have to uncheck "encrypted" in Time Machine and it insists on REMOVING the encryption and reformatting as "case sensitive". Really frustrating!
Any solutions knowns? My system drive isn't case sensitive.
Reading more, it seems backing up to AFPS requires case sensitive. I will hope restoring works. Perhaps I will do some tests after the backup.
eclecticlight.co
eclecticlight.co
Time Machine to APFS: First full backup
The first full backup is performed as a manual backup, and largely occurs in file-by-file copying from source to the backup store. It is more efficient than to HFS+, but differences could be less t…
eclecticlight.co
What should you do when your Time Machine backups go awry?
Problems with the file system of Time Machine backups haven’t gone away with APFS. As there’s no way to copy your backup volume, how to tackle such problems?
eclecticlight.co
Don't worry. It will work fine. Time Machine, Migration Assistant and Finder know how to read the TM backup file system. Nevertheless, always good to do some restoration tests.
For compatibility with linux where case-sensitive is the standard. E.g. if you're cloning a git repo with two filenames that differ only in case in the same dir.
Yes, there are reasons. And the Linux actually get it right. The rest are just trying to support their past mistakes and laziness.
Let's name a few most important:
- A case INsensitive file system introduce significant Internationalization problems.
The operating system will have to implement and perform functions like lower/upper case on all operations involving file names for each operation on the file. This may not sound like a big problem for an average English speaker. Well, there are 149186 different Unicode characters, some of them being upper and lower case letters in various languages from the world.
The MacOS kernel will have to convert every file name for every language in this world to lower case. And it should do this according to standards. The kernel file system driver is not the best place to include complex internationalization libraries. But wait, aren't the standards change with time? Yes, they are. Original characters conversion codes including Unicode standard were updated many times in the past. Old software that implemented upper to lower case conversion based on an older standard may stop working when dealing with new conventions.
More, various Unicode implementations of Unicode upper to lower functions were buggy and continue to be buggy due to the complexity of the various languages rules and depending on the conversion standard they implement. I contributed to one myself and I discovered bugs after many years despite a lot of projects where using it.
- The Unicode Standard is a Work In Progress, specially when it gets to supporting less-common writing systems and languages. English is quite well supported but once you start mixing Brahmic, Arabic, Armenian, Bengali, Bopomofo, Cyrillic, Chinese, Japanese, Hebrew... (just to name a few)... various problems may emerge with the software.
Are those conversions consuming CPU cycles? Yes they are! Somebody will say, that's nothing, just a lookup into a table. And he is right despite FS operations are a big percentage of any computer operations. But once you don't care about any performance issue, that's only the beginning of many similar bad choices. MacOS and Windows contains many lazy decision that are forcing users to spend much more money on expensive hardware... compared to what they actually should if the programmers where a little bit more careful...
- Many Linux native FS don't have this internationalization problem, any character stay the same no matter how standards change. For those FS any character in a file name is simply an unique integer number. It doesn't matter if it's an upper letter or not. No conversions are made. Kernel FS drivers doesn't keep unnecessary character conversion tables in ram for doing unnecessary conversion. That's why Linux remain the top choice for servers serving billions of users, a market where any mistake like this comes up to hunt you in benchmarks, your data-center energy consumption and your pocket.
- With more peoples using computers in their native language most OS and software will migrate to case sensitive and stop propagating the mistakes they did in the past, which is actually the only reason why we still have this choice today.
- Another common problem is related to the fact many modern programming languages implements case sensitive naming conventions for their files. An insensitive FS can quickly become a nightmare for a programmer. You may face many different packages, coming from different sources. For example one library called Driver, another one called DriVer - something related to versioning. When those libraries are packed together it may create problems in case insensitive FS. You will say: just rename the package. Well it is not always possible to simply rename them because they maybe part of external libraries out of your control or libraries used by other libraries. However even if possible it will be a complete waste of time. Libraries update often, and when they do you will have again to rename them, and rename the hundreds of occurrences in the code where they are referenced, again and again. Better just move on case sensitive FS and get rid of the problem itself!
Last edited: