181–190 of 228 posts
Earlier quoted context omitted.
I feel like we should have solved the naming problem as an industry by now. Alas.
It’s actually the hardest one of the three, being outside the grasp of formal methods.
Earlier quoted context omitted.
"Hope this helps" I see it with HAND "have a nice day" too
I've always read it as "Happy To Help". I see that's wrong, but ignorance has made the internet seem just that little bit warmer all these years!
Earlier quoted context omitted.
Yes, but no sensible people use case-insensitivity on Linux, and the amount of other people that do in a relevant context can probably be measured with four digits.
May I ask why? Case sensitivity is one of the things that really bothers me on Linux, it causes me to make mistakes for no reason. If I ever really switched to Linux full-time, I’d probably want to change that.
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 mistaken expectation that "y.txt" is the same as "Y.txt") — I don't like when computers lie to me; do you?
As every lie, this one has weird consequences. One of them is the today's RCE in OP. Another one was CVE-2014-9390. Myriads others.
Linux rejects the whole notion of filename case-insensitivity, and demonstrates how computers actually work. It becomes easier on developers and more secure on users.
Lastly, don't feel that I'm attacking you; I'm opposing an idea. So, here's a tip: you can set up case-insensitive filename completion in bash, so that TAB will correct your casing mistakes for you. It's a simply one-line change involving putting `set completion-ignore-case on` into an inputrc.
Earlier quoted context omitted.
May I ask why? Case sensitivity is one of the things that really bothers me on Linux, it causes me to make mistakes for no reason. If I ever really switched to Linux full-time, I’d probably want to change that.
> 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…
In computers yes, but i am a human and to me as a human 'A' and 'a' are the same letter.
Earlier quoted context omitted.
If linux doesn't normalize unicode at all, can you have two different files that look like they are named `josé`, depending on if the é is decomposed or not?
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.
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 be interpreted as ASCII) makes it impossible to show file names to users. That’s insane.
> This vulnerability affects platforms with case-insensitive filesystems with support for symbolic links, when certain clean/smudge filters are configured globally (e.g. Git LFS). Can we get the title changed to "on macOS and Windows?" I was worried for a second, but this is meaningless.
That isn't correct; it's a bug that manifests on case-insensitive[1] filesystems.
My colleagues who run a linux VM (our product targets Linux only) tend to git-clone onto a mounted NTFS partition so they can access the source from both host and guest. This bug will affect them even though they are running on Linux.
My other colleagues who run an actual Linux box tend to use a fast removable drive to git-clone (so they can work on it from home), and said drives tend to be FAT, which will also be susceptible to this bug.
If, on the third hand, you're running Windows and using ext4 as a filesystem (removable drive, mounted partition, whatever), then this bug should not affect you.
TLDR; the OS doesn't matter, the filesystem does.
[1] They aren't, not really; NTFS is case-sensitive! It preserves the case when writing filenames and ignores it when reading filenames.
Earlier quoted context omitted.
I thought the two hardest problems were: 1) naming 2) cache invalidation ... 3) off-by-one errors
You forgot 0) Race consegmentation fault (core dumped) (I know I was ninja’d but didn’t see until after)
Earlier quoted context omitted.
I feel like we should have solved the naming problem as an industry by now. Alas.
It’s actually the hardest one of the three, being outside the grasp of formal methods.
- a good name should be descriptive
- avoid being overly clever, call a spade a spade
- don't optimise for generalisation, naming things is a time to be specific
- aim for short but not at the expense of losing context
- avoid redundancy in naming of things nearby, leverage spatial context
- avoid qualifiers or type information where possible - type should be obvious from context and use, if it's not qualify or refactor
Anything else?