Re: Rationale for aligning data on even bytes in a Unix shell file?

On 2025-04-28, Michael S <already5chosen@yahoo.com> wrote:

On Mon, 28 Apr 2025 17:03:46 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>

Bonita Montero <Bonita.Montero@gmail.com> writes:

Am 28.04.2025 um 16:24 schrieb Scott Lurndal: 

Bonita Montero <Bonita.Montero@gmail.com> writes: 

Am 28.04.2025 um 11:39 schrieb Bonita Montero:
 

Am 28.04.2025 um 11:31 schrieb Muttley@DastardlyHQ.org: 

 

Yes, Unix-APIs are really achaic. When you have a filename
written with ohne user's locale and another with a different
locale reads that he get's at most a partitially readable
filename. For Janis this seems to be flexibility, but for me
that's a problem. A file- system should have fixed charset, at
best Unicode. 

>
I did have a look at how macOS / APFS handles this:
for macOS all filenames are UTF-8. 

 
No, unix (and macOS _is_ unix) filenames are a simple stream of
bytes with no meaning or semantic associated with the bytes other
than the terminating nul character and the directory separator
character. 

>
The Wikipedia says that APFS is UTF-8 capable.
https://en.wikipedia.org/wiki/Apple_File_System 

 
So is linux.   The operating system ascribes no meaning to the bytes
stored in the filesystem directories.   They're just a stream of
bytes.
 

>
That's nonsense.
Every case-preserving case-insensitive file system has to understand
characters encoding, at least to a certain degree.

Commonly used filesystems on Linux are case sensitive.

Apple file systems can be configured to be case-sensitive, but it's not
default and recommended for none-specialist users.

It's a really, really idiotic thing tht has become more so in
the Unicode age.

Why is there case insensitivity at all? Because some people
can't handle 'a' and 'A' being different.

But in Unicode, there are multiple ways of encoding characters
such that they result looks exactly the same.

If you're going to treat 'a' and 'A' the same, you must
also treat multiple ways of encoding the same character
as the same: whether it is multiple code points that combine
as a grapheme cluster, or a dedicated code point or whatever.

If you treat 'a' and 'A' as the same, but different grapheme
clusters denothing the same character as different, you have
a gaping inconsistency.

To correctly do the idiotic thing you're doing, you have
to bake knowledge of all Unicode into your namei() routine,
along with megabytes of data to support it.

Or you could just compare byte strings and punt that to the user as
their problem if they write the same name in two ways.