On Thu, Feb 24, 2022 at 09:52:28AM -0500, Derrick Stolee wrote: > On 2/15/2022 10:59 AM, Jeff Hostetler via GitGitGadget wrote: > > From: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx> > > > > 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. > > 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". > > > +# 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) > > +# > > + > > +# 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
