221–228 of 228 posts
> This vulnerability affects platforms with case-insensitive filesystems... What kind of platforms use case-insensitive filesystems?
Linux these days actually. You can make ext4 case insesitive. https://www.collabora.com/news-and-blog/blog/2020/08/27/usin... Note: I also learned this today. Had no clue.
Earlier quoted context omitted.
That's a dishonest statement and misrepresents the actual support. The "junctions" are unusable as "windows symlinks". For one, you can't create any as a normal non-admin user without specific authorization by default.
Only the most sadistic company on earth is going to ask you to do development on a Windows machine without admin privileges.
Earlier quoted context omitted.
> mistakes for no reason Don't you think that 65 ≠ 97 is sufficient of a reason?.. I mean, 'A' ≠ 'a', in ASCII, Unicode and even EBCDIC. In computers, those are two distinct characters. This fact won't change no matter how you rationalize your expectations. Thus, pretending that "y.txt" is the same as "Y.txt" is an elaborate lie. Even acknowledging that it's a "white", well-intentioned lie (designed to preserve the m…
> Don't you think that 65 ≠ 97 is sufficient of a reason?.. [...] In computers, those are two distinct characters In computers yes, but i am a human and to me as a human 'A' and 'a' are the same letter .
We do have the options to ignore the fact and say "What bytes? I don't care. Guess what I mean, and lie to me as well as you can so I can stay happy in my ignorance" — but, see, coordinating good support for that isn't easy. Minor wrinkles in it continue causing burns, sometimes RCEs. Maybe "doing in Rome as Romans do" isn't such a bad advice after all?
Earlier quoted context omitted.
> mistakes for no reason Don't you think that 65 ≠ 97 is sufficient of a reason?.. I mean, 'A' ≠ 'a', in ASCII, Unicode and even EBCDIC. In computers, those are two distinct characters. This fact won't change no matter how you rationalize your expectations. Thus, pretending that "y.txt" is the same as "Y.txt" is an elaborate lie. Even acknowledging that it's a "white", well-intentioned lie (designed to preserve the m…
Why is this an unacceptable lie but the notion of letters instead of code points is acceptable? Especially one you get into multi-byte characters?
It's almost comical: people continue insisting on "letters not code points" knowing very well how computers are bad with guesswork and under-defined notions. Issues stemming from that keep coming up. What if, instead, the norm accepted that 'A' ≠ 'a' and stopped creating problems which computers are known to deal poorly with?
Earlier quoted context omitted.
Why is this an unacceptable lie but the notion of letters instead of code points is acceptable? Especially one you get into multi-byte characters?
I didn't say it's unacceptable, neither meant that. In many contexts, it'd be tough without case-insensitive regex matching, for example. Reinforcing my point, //i gains issues once applied to the entirety of Unicode. It's almost comical: people continue insisting on "letters not code points" knowing very well how computers are bad with guesswork and under-defined notions. Issues stemming from that keep coming up. Wh…
Earlier quoted context omitted.
Yes, for linux filenames are just bytes. Apart from / and NUL characters it doesnt care what you give it, nor does it mangle them anyway, its the only sane thing to do.
The only sane thing to do if you don’t care about how humans (as opposed to nerds) think. In the end, the file system doesn’t exist in isolation, it is there to support users, and most of them won’t care how many bytes “é” takes to store. Unix, by not even defining the way to interpret the bytes of file names (one can’t even assume that names consisting of only bytes that correspond to ASCII letters and digits should…
At the FS layer, I think that's better. Makes things simpler for programs. For non-techie humans, unicode can be normalized at upper levels, like the GUI file manager or toolkit library that does save dialogs, etc.
That's if humans being confused because of lack of normalization of unicode is a real practical issue and not just something that can happen but never does.
Earlier quoted context omitted.
Nope. This is an example of someone working on company time using their personal email.
Right, which is (AFAIK) not usually recommended except for side projects or ones where there is already an existing relationship under a personal email address.