change case sensitive HDD (APFS) to non case sensitive

I have been solve it with a temporary method, see my blog: https://blog.vrqq.org/archives/213/ .

I just create a volume(case-insensitive) using "Disk Utility.app" and re-mount this volume on '~/Library/Application Support/Steam' folder.

Hope for helping you.

Unfortunately not an answer, just a warning that making a time machine backup, restarting with the recovery system, reformatting the system into APFS case insensitive, this did NOT work because later when it restores from Time Machine, it will reformat the system *again* into the original APFS case sensitive.

So I've retried the process and I could not figure out any simple way to do it.

Using the Migration Assistant, by installing a new system and then running the app, will refuse to pick up my Time Machines (I have one on a 2.5" USB disk, and a second copy on a Time Capsule), saying that both "are case sensitive and thus not eligible"

So then I tried to access the TimeMachine backup, latest date, and copy my whole user folder into a temporary on the new clean system… which failed as I do have files with the same name and mixed case somewhere under Library. Finder just shows the error and stops, without the choice of "keep both" or "replace" or anything.

I'm now on a new clean system and recovering my data step by step. Bummer.

The "let's keep beta out" was a note for me and any reply to not go further in detail, than that paragraph, which should still be public on archive.com or somewhere else. There was indeed a case where HFS did get converted into APFS+Case Sensitive, for some people, and the when and why is not relevant here. I "suspect" that it may have been related to also having encryption, as my home Mac mini, running the same betas as my MBP, at the same time, is with regular APFS case insensitive.

Back to the original thread, I'd say again that I'm pretty sure that there is no way to convert case sensitive into case insensitive without doing it manually. Even copying the data manually, folder by folder, from my time machine to my newly installed system, is showing duplicate filenames in so many unexpected places that I'd strength again that case insensitive file systems are a huge mistake, and as soon as Adobe fixes their act (which I doubt they will), I'll go back to case sensitive all over again.

"The first developer preview of APFS, made available in macOS Sierra in June 2016, offered only the case-sensitive variant. In macOS 10.12.4, the APFS developer preview was updated to also include a case-insensitive variant. In iOS 10.3, the case-sensitive variant of APFS is used."

Let's keep the beta discussion out of this thread and just keep the relevant points that case sensitive (as well as normalization) does make sense, but Apple had to cave in and support Adobe and others - only on macOS, as iOS does not support case insensitive, fortunately.

I'm just curious as to why anyone would use the case-sensitive format. Macs have defaulted to case-insensitive since the dawn of time. Which would explain why Steam or just about anything else wouldn't support it. I'm not sure why Apple still makes it available for that matter.

Unfortunate beta testers that got their root filesystem migrated to APFS before APFS supported case-insensitive, and only recently felt the need to reinstall Adobe software (Lightroom) and discovered the state of the FS.

In the past I did the same mistake with HFS because I was getting tired of having issues with file renaming (Eclipse refactor/rename vs. git, but it could happen with any tool) when I was trying to rename some java classes to not have more than a single upper case on the camel case names (e.g. FooHTTP into FooHttp) and by renaming them on Eclipse - so the whole code gets updated - the filesystem sometimes would acknowledge the change, sometimes it would not, getting into a huge mess, as Eclipse would show the correct names, but then compiling the java code would produce classes with the incorrect capitalization.

What I'm curious is how can a software house like Adobe and Steam not support a proper filesystem. I'm really sad that Apple had to implement a case insensitive file system just for the sake of those kind of legacy broken apps. But hey it's hard to live without some Adobe software, and people like to play games.

davipt wrote:

Unfortunate beta testers that got their root filesystem migrated to APFS before APFS supported case-insensitive, and only recently felt the need to reinstall Adobe software (Lightroom) and discovered the state of the FS.

Sorry to interrupt but I don't understand your reply. I've run the developer betas of High Sierra since the first release of 10.13 last year. It defaulted to APFS case-insensitive. So I'm somewhat confused.

I thought we were in the High Sierra community. Not that it matters, I also ran the developer betas of Sierra and they didn't convert anything to APFS.

As far as this…

Let's keep the beta discussion out of this thread

I wasn't the one that brought it up.

davipt wrote:

Unfortunate beta testers that got their root filesystem migrated to APFS before APFS supported case-insensitive, and only recently felt the need to reinstall Adobe software (Lightroom) and discovered the state of the FS.

Betatesting is a test, the beta software is not yet ready for release. Using it on a production machine is madness. If you want to work don't use beta's, if you want to take part in a test, use the beta. This does not seem to be very complex.

I don't know what is your name, but I'm sure you wouldn't like to be called csOUNd1 or something like that, would you?

Likewise, Java class names are case sensitive, and the CamelCase name of the class inside the file must be the same as the case of the .java file.

Web files on a HTTP server are also case sensitive. InDeX.HtMl is not the same as index.html. However, when testing locally, the local browser will ask the local http server (or whatever development tool provides the local service) will request "index.html", and the *stupid* file system will return "yeah I have an InDeX.HtMl which is the same". Everything works until you go to production and everything fails.

And then you know it failed, and do a rename of the "InDeX.HtMl" into "index.html", and the *stupid* file system "may" say "sure, I'll pretend I'll rename it, as for me they are the same, so I'm gonna say I did it, and did nothing".

I understand that for most people (me non professionally included) the name of a image file is a bit irrelevant, but for professional usage, we don't want random ghosts hunting us down with this kind of problems.

Just look at this madness on the command line:

$ echo a > FooBar

$ cat foo<tab> <-- no expansion as there's no file named foobar…

$ cat foobar <-- …or is there? some file exists of course

a

$ echo b > foobar <-- I've created a small caps foobar now right? it's a new file!

$ ls *o*

FooBar <-- nope, it's a completely new file, but it's still keeping the previous name

$ mv FOOBAR foobar <-- wait, all caps?

$ ls *o*

foobar <-- and this is where everything failed for me, as "mv" does the right calls and does rename it properly, but some apps (Eclipse), specially in combination with git hooks, may not rename it properly - "maybe" it was a bug on HFS that is solved on APFS though. Eclipse would rename FooBAR into FooBar. Git would see the change and ask for the differences between FooBAR and FooBar (which are none, besides the filename), but depending on how long it would take between the rename and the fsevent hook, the HFS could return "what do you mean, FooBAR is exactly the same as FooBAR", or could return that there were really a rename. This *****. Pure madness.

Agreed. I think I'm starting to remember why I didn't come back. Good to see you though.

I'm curious why anyone would format an HDD to APFS since Apple does not convert them.