On Jan 21, 2008, at 4:17 PM, Martin Langhoff wrote:

quoted text
> On Jan 22, 2008 9:53 AM, Kevin Ballard <kevin@sb.org> wrote:
>> On Jan 21, 2008, at 3:33 PM, Linus Torvalds wrote:
>>> Umm. What's this inability to see that data is data is data?
>>
>> I'm not sure what you mean. I stated a fact - at least on OS X, the
>> filename does not contribute to the listed filesize, so changing the
>> encoding of the filename doesn't change the filesize. This isn't a
>> philosophical point, it's a factual statement.
>
> Kevin,
>
> as you might know, Linus' "other hobby" is to write kernels ;-) From
> taht POV, a filename is as much data as the data in the file. Doing
> odd things like sorting it, searching through it, etc, is all work for
> code higher in the stack that is free to mangle the data in any way it
> wants, including creating nice case-insensitive indexes, and
> who-knows-what for ideogram-based languages. In contrast, the core OS
> treats user data a sacred stuff, and I'm thankful it does.

That's certainly a reasonable POV. However, it's not the only one. As =20=

evidenced by the Mac, treating filenames as strings rather than bytes =20=

is a viable alternative POV - you can't argue that it doesn't work, =20
because OS X proves it does.

However, it is a trade-off.

quoted text
> And from a kernel/filesystem POV, a directory is also a file. So if a
> filename has a different number of octets, the directory will be
> different.

Sure, that makes sense. That's why, if you are going to mangle =20
filenames, you need to pick a stable form to always use, which HFS+ =20
does.

quoted text
> For all the searching and matching, it really makes sense to have
> something like locate or SpotLight or whatever to index user files
> that should be easy to find and match, because all the locale rules
> for matching are hideously expensive to apply. Even today, most UTF-8
> aware (and supposedly collation-smart) applications have trouble
> matching MART=CDN when asked for mart=EDn in a case-insensitive =
search.
quoted text
> That pesky latin =ED trips them up everytime.


Perhaps you should try OS X. Every single Cocoa app should do the =20
search properly. In fact, I just checked using 3 different text =20
engines (WebKit, Cocoa's text engine, and ATSUI) and all 3 did the =20
case-insensitive search properly. That said, this isn't particularly =20
relevant.

-Kevin Ballard

--=20
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com