Case-insensitive ext4

Posted Mar 28, 2019 19:11 UTC (Thu) by jccleaver (subscriber, #127418)
In reply to: Case-insensitive ext4 by mathstuf
Parent article: Case-insensitive ext4

Ultimately, this really brings to mind how important initial design is for things.

Classic Mac OS was designed with case-insensitivity in mind, had no manual tools that needed to be imported with minimal effort rather than a complete rewrite, and had no shell mechanics to emulate.

Case Insensitivity #JustWorks when people expect it and are going through translation layers (and aren't in the business of writing drivers), and doesn't when people assume low level access.

Case-insensitive ext4

Posted Mar 28, 2019 20:14 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (2 responses)

I still wonder how this would have worked even on Classic Mac OS. Do you just assume that *all* paths can be normalized regardless of location or host filesystem? If so, do you just not support filesystems with alternate paths? Though I suppose the Windows solution of mangling unsupported names on the render side works too[1]. However, this means that any path manipulation has to do a syscall to get some canonical representation of a path or each program has to have a "pathcmp" function to determine that "foo" and "FOO" are really the same thing.

Would you have expected the shown Makefile snippet to work on Classic Mac OS or would an error that "no rule to make FOO" be acceptable?

[1]Making a path appear in Explorer via a network share with the name "CON1" renders as some mangled name. Creating a file with that mangled name then shows two files with the same name appear. Deleting either one via the UI deletes the one with the real mangled name first (I assume given a HANDLE, they can be differentiated).

Case-insensitive ext4

Posted Mar 28, 2019 20:35 UTC (Thu) by k8to (guest, #15413) [Link]

Yeah, mounting case sensitive filesystem on classic MacOS would have been messy. I'm sure I did this at some point with e.g. Basilisk II mounting the Linux filesystem underneath it, but that had a hefty translation layer to support the other oddities of classic MacOS like forks etc.

I think that was the approach taken by other people too, probably one of Apple Single or Apple Double representations which probably had some solution for NFS which was still in vogue in the 90s.

It wasn't that nice an experience for the Mac users or the non-mac users. I never programmed against it to experience the extra sharp edges, though.

Case-insensitive ext4

Posted Mar 28, 2019 21:01 UTC (Thu) by jccleaver (subscriber, #127418) [Link]

> Do you just assume that *all* paths can be normalized regardless of location or host filesystem?

I think by System 7.5 (or 7.1 Pro) you did, because if I recall correctly that's how File Exchange/PC Exchange did its work.

Remember, in classic Mac OS the colon ':' was the directory separator in paths, and you could use '/'s to your heart's content. Actually, you could use pretty much anything to your heart's content, including spaces, punctuation (since no one in the Mac side cared about extensions) and even weird graphs like the f-hook or florin https://en.wikipedia.org/wiki/%C6%91#Appearance_in_comput... , which I still find myself occasionally doing on OS X 20 years later.

Anyway, with /. \. and : being used in different locations, there was definitely path-mangling going on below the interface. But general users didn't have to care, and most Mac programs didn't deal with constructed path names, and *never* had to worry about shell-quoting for spaces and whatnot.

Between this freeform text attitude, the resource and data fork dichotomy, and the use of Type and Creator codes, I definitely feel like we've lost some good capabilities on the Mac side in the quest for broader interoperability.