6 ms·

This feels in some sense like punting the problem. What exactly should the presentation layer do when presenting two files, where the first is named with a prec

This feels in some sense like punting the problem. What exactly should the presentation layer do when presenting two files, where the first is named with a precomposed character sequence, and the other has the same name but decomposed? Surface the normalization form the user? Uh, no... The more fundamental question is whether filenames are under control of the user or the system. The answer today is "both": there's blessed paths /System/Library... and non-blessed paths like ~/Documents/Pokemon.txt. Addressing this properly means reifying that distinction: making apps always be explicit about whether they're working with the user's or the filesystem's view of a file. While we're here, why the should the user even have to name every file? Do you name every piece of junk mail on your desk/kitchen island? The ideal for the user is something like tagging, where naming stuff is optional, names are forgiving and perhaps not unique, and files are not restricted to being in one directory. Meanwhile, filesystem names are an implementation detail and the filesystem enjoys Unicode ignorance. Spotlight moved a bit in this direction, but the end goal is still awfully far away.

Ericson2314 10y ago
I'd argue: Use a langauge with generics and make the path type a ((de-)serializable) black box. You still need to make a decision in the end, but are much more free to change it.
- jstimpfle 10y ago
  This is not a language issue.
  - Ericson2314 10y ago
    I didn't say it was. I said generics would help one easily switch their choice on the different semantics, not avoid choosing at all.
    - jstimpfle 10y ago
      Many, or most, languages already do that by representing filenames as native strings (which are usually abstract "Unicode" strings).
      - Ericson2314 10y ago
        I want to swap the path type used by the FS implementation. This is totally distinct from a langauge providing some string type which while abstract is nevertheless fixed and unchangable.
- daenney 10y ago
  Both Objective-C and Swift have (a form of) generics on board.
panic 10y ago
The more fundamental question is whether filenames are under control of the user or the system. The answer today is "both": there's blessed paths /System/Library... and non-blessed paths like ~/Documents/Pokemon.txt. Addressing this properly means reifying that distinction: making apps always be explicit about whether they're working with the user's or the filesystem's view of a file. This distinction is important for other reasons, too. Should this file be indexed for search? Should it store an access time to support features like "recently opened"? On the other side, we want to know which blessed paths "belong" to which system application or service so we can sync them, protect access to them, and uninstall them with their owners. Maybe the user-visible document store should be a separate mechanism entirely from low-level app/service data persistence.
comex 10y ago
> What exactly should the presentation layer do when presenting two files, where the first is named with a precomposed character sequence, and the other has the same name but decomposed? Show two files with apparently identical names. Is that so surprising? There are many many ways for two different Unicode strings to look visually identical (or near-identical) even if they aren't equivalent under normalization. For that matter, even if you were limited to plain keyboard ASCII, you could have two really long filenames that only differ in one character, which are effectively indistinguishable without massive hair-pulling. If you want to be robust, there's no way around having means to identify files other than names. (I agree with your sentiment about tagging.)
- rurban 10y ago
  You are talking about confusables. Unfortunately normalization cannot handle this. Only certain apps treat confusables as confusables: email, web browsers, dns services, usually via libidn.
- askvictor 10y ago
  Google drive allows you to have identically named files in the same directory. Doesn't quite map onto a desktop filesystem, but the filename is not a unique identifier, but just a convenience for the user or application.
- jameshart 10y ago
  Even with normalization, you can just sprinkle an arbitrary selection of non breaking zero width space characters into a string and create an infinite variety of identical-looking but distinct codepoint sequences. Treating filenames as bundles of bytes is fine, but at that point it seems dangerous to assume that interpreting them as encoded strings is a valid way of distinguishing them.
- kbenson 10y ago
  > For that matter, even if you were limited to plain keyboard ASCII, you could have two really long filenames that only differ in one character, which are effectively indistinguishable without massive hair-pulling. My initial response was to not present confusing data to the user, but then I thought of exactly this. In many fonts, lowercase "L" (l) and uppercase "i" (I) look the same. I'm sure in some fonts they actually are identical, rather than just being nearly indistinguishable to the human eye. To the discussion is not about whether we should present confusing identifiers to users, but at what point if it becomes more common does it cause enough of a problem to be a bad choice, and what techniques are there to mitigate it?
nradov 10y ago
Microsoft tried to do something like your ideal with WinFS but couldn't make it work and abandoned the project.

Ericson2314 10y ago

I'd argue: Use a langauge with generics and make the path type a ((de-)serializable) black box. You still need to make a decision in the end, but are much more free to change it.

jstimpfle 10y ago
This is not a language issue.
- Ericson2314 10y ago
  I didn't say it was. I said generics would help one easily switch their choice on the different semantics, not avoid choosing at all.
  - jstimpfle 10y ago
    Many, or most, languages already do that by representing filenames as native strings (which are usually abstract "Unicode" strings).
    - Ericson2314 10y ago
      I want to swap the path type used by the FS implementation. This is totally distinct from a langauge providing some string type which while abstract is nevertheless fixed and unchangable.
daenney 10y ago
Both Objective-C and Swift have (a form of) generics on board.

panic 10y ago

The more fundamental question is whether filenames are under control of the user or the system. The answer today is "both": there's blessed paths /System/Library... and non-blessed paths like ~/Documents/Pokemon.txt. Addressing this properly means reifying that distinction: making apps always be explicit about whether they're working with the user's or the filesystem's view of a file. This distinction is important for other reasons, too. Should this file be indexed for search? Should it store an access time to support features like "recently opened"? On the other side, we want to know which blessed paths "belong" to which system application or service so we can sync them, protect access to them, and uninstall them with their owners. Maybe the user-visible document store should be a separate mechanism entirely from low-level app/service data persistence.

comex 10y ago

> What exactly should the presentation layer do when presenting two files, where the first is named with a precomposed character sequence, and the other has the same name but decomposed? Show two files with apparently identical names. Is that so surprising? There are many many ways for two different Unicode strings to look visually identical (or near-identical) even if they aren't equivalent under normalization. For that matter, even if you were limited to plain keyboard ASCII, you could have two really long filenames that only differ in one character, which are effectively indistinguishable without massive hair-pulling. If you want to be robust, there's no way around having means to identify files other than names. (I agree with your sentiment about tagging.)

rurban 10y ago
You are talking about confusables. Unfortunately normalization cannot handle this. Only certain apps treat confusables as confusables: email, web browsers, dns services, usually via libidn.
askvictor 10y ago
Google drive allows you to have identically named files in the same directory. Doesn't quite map onto a desktop filesystem, but the filename is not a unique identifier, but just a convenience for the user or application.
jameshart 10y ago
Even with normalization, you can just sprinkle an arbitrary selection of non breaking zero width space characters into a string and create an infinite variety of identical-looking but distinct codepoint sequences. Treating filenames as bundles of bytes is fine, but at that point it seems dangerous to assume that interpreting them as encoded strings is a valid way of distinguishing them.
kbenson 10y ago
> For that matter, even if you were limited to plain keyboard ASCII, you could have two really long filenames that only differ in one character, which are effectively indistinguishable without massive hair-pulling. My initial response was to not present confusing data to the user, but then I thought of exactly this. In many fonts, lowercase "L" (l) and uppercase "i" (I) look the same. I'm sure in some fonts they actually are identical, rather than just being nearly indistinguishable to the human eye. To the discussion is not about whether we should present confusing identifiers to users, but at what point if it becomes more common does it cause enough of a problem to be a bad choice, and what techniques are there to mitigate it?

nradov 10y ago

Microsoft tried to do something like your ideal with WinFS but couldn't make it work and abandoned the project.