5 ms·
The real problem isn't whether filename normalization is a good/bad thing, the problem is Apple used to do it one way and is now switching without warning to do
by cstross 9y ago
The real problem isn't whether filename normalization is a good/bad thing, the problem is Apple used to do it one way and is now switching without warning to doing it the other way.
It's the logical end product of the odyssey from Apple's original philosophy of a resource and data fork model for files to the UNIX stream-of-bytes model for files. The UNIX model traditionally kept metadata about files separate (anyone else remember naughtily hand-editing directory files with sed(1), back in the day?) but gradually picked up a bunch of new stuff that has to be stored somewhere. Meanwhile, the Mac platform adopted UNIX binaries with the move to NeXTStep underpinnings (we're going back to the late 90s here, and the adoption of OSX over traditional MacOS), obviating the need for the original resource bundle, which got rid of those annoying errors about missing bundle bits but left us with a legacy of .DS_Store turdlets in every directory to hold file metadata that was formerly stored in the resource fork.
As a destination it's laudable — design consistency is almost always laudable — but it's the end goal of a very messy process and it looks like APFS isn't quite there yet; NSFileManager and NSURL need some way of distinguishing files with different unicode representations, and the Finder in particular needs to be robust. I'm guessing this is going to be fixed when High Sierra finally ships, but isn't supported in Sierra at present, hence the OP's alarm at the situation.
- vetinari 9y agoTechnically, .DS_Store is just Finder data - where is the windows displaying the directory, it's dimensions, listing mode, etc. The former resource fork is in ._$filename. You won't see it, unless you copy the file to smb share or zip it.
- klodolph 9y agoThe former resource fork not in ._$filename unless the underlying filesystem does not support it. On HFS+ volumes, which is what 99%+ of Mac users use, there will be no ._$filename file.
- vetinari 9y agoYou are correct regarding the resource fork support in the fs and it's visibility, maybe I didn't express myself as exactly as I should. However, 99%+ of Mac users do use FAT-formatted USB sticks, ZIP files, or other fs/mechanism/whatever that does not support resource forks where the compatibility littering kicks in, so they, or the people they share their files with, will see ._$filename files too. On the other hand, Finder litters with .DS_Store files everywhere, even on HFS+.
- klodolph 9y agoMost files don't have resource forks though, so the ._$filename doesn't store resource fork data in most cases. It usually just stores metadata. I really doubt that 99%+ of Mac users use flash drives / zip files, though. I suspect that well more than 1% of users never use anything like that. A lot of people only have a single computer and share through e.g. just mailing files to people or using Dropbox, or not even that.
- vetinari 9y agoWhile resource forks are deprecated and on the retreat, extended attributes are a new hotness, used extensively (just download a file in the browser, and it will get com.apple.quarantine and com.apple.metadata:kMDItemWhereFroms). These are also shoveled into AppleDouble files. Actually, resource fork is just com.apple.ResourceFork extended attribute. I'm not sure that there are more than 1% of mac users do not exchange files with other people, possibly on other platforms. What do they use the computer for, then? iPad would be more suitable then.
- mattnewton 9y agoGP is saying they don't pass around flash drives to do so, not that they don't share files.
- klodolph 9y ago
- mchanson 9y ago"without warning"? Not really. This has been discussed to death on ATP last year. Also, in regards to the headline, there are tens or maybe over a hundred million non-english speakers using iOS already running APFS...
- the_mitsuhiko 9y agoiOS never exposes low-level filenames to the user.
- JoachimS 9y agoOne of the new features in iOS 11 presented yesterday is the File App. It provides access to all files (at some level) in the system and on networked systems including iCloud, Dropbox etc.
- the_mitsuhiko 9y agoThat only ever surfaces filenames through cocoa APIs that underwent normalization.
- deleted 9y ago[deleted]
- TorKlingberg 9y agoOn iOS the user doesn't get much direct access to the file system.
- cryptonector 9y agoDid anyone mention normalization-preserving/normalization-insensitive behavior? That's what ZFS does, and it's great!
- foota 9y agoIs that not just treating the filename as a byte sequence?