On 21 April 2010 11:58, Fred Drake <fdrake@acm.org> wrote:
As such legacy fades (however slowly), should we *increase* the amount of code that deals with it, or should we move on?
It's not clear to me that it's all "legacy". I had the impression that MacOS used a case insensitive filesystem - is that right? Certainly, I know that MacOS uses Unicode normalisation, so simple string comparison is definitely not correct. (I only use MacOS as an example to avoid the assumption that this is a Windows-only issue - there are also case-insensitive filesystems available for Unix in general, if nothing else SMBFS). Certainly, non-case-preserving systems are a dying breed. But from what I've read, the situation around case sensitivity is far less clear - I've even seen comments from Unix users that claim they would like Unix to move away from case sensitivity. (I'm not qualified to judge the relevance or importance of such claims, I merely note that they exist). Like it or not, treating filenames as uninterpreted byte strings will violate some users' expectations. Library support for dealing with user expectations at a higher level would be good. Unfortunately, from my reading, it seems like at least on Linux, filesystem writers are expected to implement their own path handling (at least, that's how I interpret the FUSE documentation, and I couldn't find any lower level filesystem driver documentation that implied otherwise). So, at the filesystem level, it seems that on Linux all bets are off - I could, in theory, write a filesystem that was case insensitive for consonants, but case sensitive for vowels. And stored filenames in bit-reversed UTF-8. Bleh. Paul.