Maynard Handley (name99.delete@this.name99.org) on July 14, 2020 12:40 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 14, 2020 9:02 am wrote:
> > Brett (ggtgp.delete@this.yahoo.com) on July 14, 2020 2:34 am wrote:
> > >
> > > I too would like to know what Apple function call Linus is complaining about.
> >
> > Every single pathname function is broken shit.
> >
> > We're not talking some odd unusual specialized library function. We're talking "open()". Heard of it?
> >
> > You pass in one string to create a filename, and OS X will create the
> > file with another name and corrupt it. And do it badly at that.
> >
> > I'm not talking "Oh, you gave us badly formed input so we fixed it for you". No,
> > I'm talking "you gave us proper pathnames, and we completely screwed it up".
> >
> > Seriously. It's unbelievable garbage. Even MS got that part right, and that's saying
> > something considering they originally used UCS2 (then upgraded to UTF-16, and now finally
> > seem to have made UTF-8 the first-rate format) for their pathname interfaces.
> >
> > But it's Apple, so you can now commence your daily denial
> > routine about how what they do is right and proper.
> >
> > Hint: it isn't.
> >
> > And it results in real and present issues. Things like "oh, you have a sane cross-system
> > SCM that keeps track of the names in your directory. But they change from what they were
> > fed, and in insane and incorrect ways, so when you do 'readdir()' you get something else
> > back than what you thought, and you have to convert it back to the sane format".
> >
> > It is literally so unbelievably broken, that it breaks even trivial Latin1 filename encodings,
> > and if you ignore just plain ASCII, that's the simplest UTF-8 model there is.
> >
> > And yet Apple got even that one wrong.
> >
> > That is some truly historically incredibly bad crap. Yes, the computer industry has
> > a long and storied history of not understanding complex character sets, but what Apple
> > did approaches EBCDIC level confusion, just in a slightly more modern guise.
> >
> > Because when they change your data under you, they don't even do it in the proper sane
> > ways that you can defend as "well, we cleaned it up for you". Oh, no. Not even close.
> >
> > No, they literally picked the most shit-for-brains normal form you can pick, and said "we will screw
> > absolutely everybody over, because we think this makes it slightly easier to do icase-compares".
> >
> > Btw, they were wrong even about that "slightly easier".
> > They could easily have done their broken normalization
> > internally without ever exposing the temporary values they used. The way you should. But no. They
> > said "we are doing this anyway because we need to do it internally because we made some other fundamental
> > design mistakes, so we will now just screw everybody else over for it too".
> >
> > They were just plain incompetent, and it's actually sad how much apologia you can find over it.
> >
> > Linus
>
> Let's ask some simpler questions.
>
> Are you against the concept of filename normalization generically? So you don't just want no normalization
> of capitalization, you want name+' to be treated a separate filename from namé ?
>
> Or are you asserting that normalization is fine, but you disagree
> with some detail of what Apple considers to be normalization?
>
> Or are you saying that there are objective bugs (not different choices as to how to
> solve this problem, but objective bugs) in Apple's filename normalization code.
>
>
> So far all you have told us is that Apple is doing something absolutely awful and terrible and poopy-headed,
> without telling us anything about what it is. Given that Apple ships their OS's to a wide variety
> of countries, and supports a wide variety of languages, perhaps you can understand why some of us
> are somewhat skeptical that this represents a real bug (or even a bad choice) as opposed to simply
> "Apple didn't make the set of choices that would be maximally convenient for Linux".

I sympathize with the problem Linus has had.

The interface between filesystems and version-control is difficult. I remember a problem with this about 20 years ago.

I was working for a small company, we were using CVS for version control. There were only two or three people doing programming and it was mostly on Windows. We decided to use CVS because the alternatives were either very new or expensive proprietary products. The system administrator was a Linux nut. So, the CVS server ran on a Linux box. He also didn't trust NTFS. So, all the Windows PCs had FAT drives. It turns out this created a problem.

I went to work one day, I was tired because the clocks had changed the day before. When I got there I found that CVS had marked all of my files changed. It had marked that in every sandbox for every project. I was baffled. It turned out the problem was the change in daylight-savings-time. NTFS, Linux and *nix filesystems all use UTC dates. But, FAT doesn't, it uses the date-and-timezone set on that PC. That changes every time daylight-savings-time ends or starts. As a result, all file creation times were moving by an hour one way or the other twice a year relative to the time recorded on the Linux server. That was enough to cause CVS to mark everything as changed.

Humans don't look at all these little bits of information in the filesystem. It never occurred to me that there were any complications, but when I actually checked it was clear. "Little" problems like this can be huge problems for software. Software is more likely to rely on all these little details that are stored along with files. The problem Linus describes is a specific instance of a more general problem.