6 ms·
I think the solution is to stop trying to over-manage user- and filesystem-input. Be faithful and preserve what was entered rather than trying to "second-guess
by sacnoradhq 4y ago
I think the solution is to stop trying to over-manage user- and filesystem-input.
Be faithful and preserve what was entered rather than trying to "second-guess" the user.
- kalleboo 4y agoWhat is the solution here though? They forced normalization in HFS+ and everyone hated that even more since it changed your file names when you copied over files. And they can't be normalization-sensitive because then you can't type in a file name.
- vlovich123 4y agoI still don’t see the problem with normalization.
- hibbelig 4y agoSay that each letter has two versions, and they look exactly alike. This means there are now 8 file names that look like "foo", and it's not clear which one of them you have to type in to get the file you're looking at.
- vlovich123 4y agoThat’s exactly the problem normalization solves - all variants map the same.
- hibbelig 4y agoIm sorry, I misread what you were saying. I understood the opposite of what you were saying.
- CorrectHorseBat 4y agoI guess the issue is that if you copy files between 2 systems, one which does normalization and one which doesn't. Best would be if everyone did normalization, but that ship has sailed :(
- HPsquared 4y agoMaybe each file should have two names instead of one?
- actionfromafar 4y agoMacOS at least has file ID, so there's that.
- kalleboo 4y agoAnd even if both systems have normalization, the normalization changes with Unicode versions, so just different OS versions will cause filename conflicts.
- vlovich123 4y agoI’m not aware of that. How do JS engines implement String.prototype.normalize?
- flohofwoe 4y agoThe solution is simply what Linux does: treat filenames as bags of bytes instead of strings (but this would also include case-sensitivity). At least then the behaviour is completely straightforward and transparent down in the file system layer. UNICODE details like normalization can be handled up in the application layer.
- ClumsyPilot 4y agoDo you speak other languages? Czech language has Á, Č, Ď, Ě, É, Í, Ň, Ó, Ř, Š, Ť, Ů, Ú, Ý Á can be represented in Unicode by its spesific codepoint, or can be made up of two - Letter A and the squiggly bit. So when a user tries to fOpen a file called ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ Should by application make 2^32 requests to the file systen to open a file for every possible combination of bytes this steing could be represented as?
- FeepingCreature 4y agoTo be fair, what a sufficiently clever application could do would be to try and naively open the file, note a mismatch, then do a directory walk comparing normalized filenames. Still not great.
- flohofwoe 4y agoIdeally, un-normalized paths wouldn't even make it down to the filesystem layer. I'm just saying that it shouldn't be the filesystem's job to care about text encoding details, but the layers above it (e.g. the filesystem would work in a simple "garbage in - garbage out" mode).
- deleted 4y ago[deleted]
- flohofwoe 4y agoI speak German which has its share of pointy letters :) I'm aware of the normalization problem, but that should be handled in the API layers above the filesystem. In which layer exactly is up for discussion though (but IMHO there should always be a fallback to access files via their "raw bytes path identifiers", if for nothing else than debugging).
- shp0ngle 4y agoBut that’s exactly what they do now?
- Kwpolska 4y agoThis isn't just an issue with the filesystem, apps also randomly produce NFD. And then you copy text from a PDF in Preview to Word, and spellchecking goes haywire.