Re: [PATCH 02/23] t7527: test FS event reporing on macOS WRT case and Unicode

From: Torsten B��gershausen <tboegi@web.de>
Date: Feb 24, 2022, 17:33 UTC
Message-ID: <20220224173305.gbr2waw77xpuieub@tb-raspi4>
In-Reply-To: <c7ee2394-cda0-a997-3b9d-fb8c3d65b312@github.com>

On Thu, Feb 24, 2022 at 09:52:28AM -0500, Derrick Stolee wrote:

Show 6 quoted lines

> On 2/15/2022 10:59 AM, Jeff Hostetler via GitGitGadget wrote:
> > From: Jeff Hostetler <jeffhost@microsoft.com>
> >
> > Confirm that macOS FS events are reported with a normalized spelling.
> >
> > APFS (and/or HFS+) is case-insensitive.  This means that case-independent

This is not true, strictly speaking. You can format a disk with "case sensitive" or "case-insenstive, case preserving". Both APFS and HFS+ can be formated that way. The default, which is what you get when you get a new machine, is "case-insenstive, case preserving". And I assume, that more 99% of all disks are formated that way. The "core.ignorecase" is used in the same way as it is used under NTFS, FAT or all other case-insenstive file systems. (and even ext4 can be formated case-insensitive these days.)

An interesting article can be found here: https://lwn.net/Articles/784041/

And to be technically correct, I think that even NTFS can be "configured to be case insensitive in an empty directory".

In that sense, I would like to avoid this statement, which file system is case insensitive, and which is not. Git assumes that after probing the FS in "git init" we have a valid configuration in core.ignorecase.

Show 18 quoted lines

> > lookups ( [ -d .git ] and [ -d .GIT ] ) should both succeed.  But that
> > doesn't tell us how FS events are reported if we try "rm -rf .git" versus
> > "rm -rf .GIT".  Are the events reported using the on-disk spelling of the
> > pathname or in the spelling used by the command.
>
> Was this last sentence supposed to be a question?
>
> > NEEDSWORK: I was only able to test case.  It would be nice to add tests
>
> "I was only able test the APFS case."?
>
> > that use different Unicode spellings/normalizations and understand the
> > differences between APFS and HFS+ in this area.  We should confirm that
> > the spelling of the workdir paths that the daemon sends to clients are
> > always properly normalized.
>
> Are there any macOS experts out there who can help us find the answers
> to these questions?

There is a difference between HFS+ and APFS. HFS+ is "unicode decomposing" when you call readdir() - file names are stored decomposed on disk once created. However, opening file in precompsed form succeds. In that sense I would strongly suspect, that any monitors are "sending" the decomposed form (on HFS+).

APFS does not manipulate file names in that way, it is "unicode normalization preserving and ignoring".

Show 11 quoted lines

>
> > +# Confirm that MacOS hides all of the Unicode normalization and/or
> > +# case folding from the FS events.  That is, are the pathnames in the
> > +# FS events reported using the spelling on the disk or in the spelling
> > +# used by the other process.
> > +#
> > +# Note that we assume that the filesystem is set to case insensitive.
> > +#
> > +# NEEDSWORK: APFS handles Unicode and Unicode normalization
> > +# differently than HFS+.  I only have an APFS partition, so
> > +# more testing here would be helpful.

I have an older system and may be able to help, (but am busy this week)

Show 5 quoted lines

> > +#
> > +
> > +# Rename .git using alternate spelling and confirm that the daemon
> > +# sees the event using the correct spelling and shutdown.
> > +test_expect_success UTF8_NFD_TO_NFC 'MacOS event spelling (rename .GIT)' '

Isn't this precondition is the wrong one and CASE_INSENSITIVE_FS is a better one ?

[snip]

I diddn't follow you series, but if there is a need to test under MacOS with HFS+, feel free to cc me in the next round