41–50 of 228 posts
Can we get the title changed to "on macOS and Windows?"
I was worried for a second, but this is meaningless.
Earlier quoted context omitted.
MacOS and Windows
In windows, the underlying ntfs is still case sensitive, and that gets made use of with the WSL 1.0 stuff.
Starting with Windows 10, the aforementioned key still works, but there's also a per-directory case-sensitive flag that forces all DOS and Windows programs to have case-sensitive operations unconditionally. This is made to great effect in both WSL1 and Cygwin.
Earlier quoted context omitted.
Difficult problems in programming: (1) cache invalidation (2) off-by-one errors
Per your downvotes - I used to hate jokes on Hacker News and downvote them when I saw them, but I've become more ambivalent. They're a way of amicably sharing culture and experiences with other engineers that transcend any differences in age, gender, race, background, etc. The formulation of this joke I tend to see is, The two hardest problems in programming: (1) cache invalidation (2) appropriately naming things (3)…
(Cache invalidation is essentially the same problem as managing mutable state -- "Out of the Tar Pit" frames mutable state as either essential or incidental, the latter being rederivable in principle from essential state. Incidental mutable state is no more and no less than a cache, and usually one with an informal and undocumented invalidation policy.)
(And naming things has a very real technical counterpart in addressing, which comes up obviously in networking, but you can also see its shadows in quite a lot of concerns around architecture and modularity.)
Earlier quoted context omitted.
OSX has even more annoying problem that it decomposes unicode: https://stackoverflow.com/questions/5581857/git-and-the-umla... Many fun times trying to copy/move/remove a file and not being able to do so because the input and name stored on fs is actually different bytewise... Seems like linux has the only sane filesystems not trying to mangle paths at all.
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?
> 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.
> 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.
There are many options for case-insensitivity on Linux. The common one would be FAT, which can't handle symbolic links, so that is moot. There is also ext4 and ZFS that can have case-insensitive modes enabled (they aren't by default), which do support symbolic links. ntfs-3g also has an option to mount as case-insensitive (though said option can actually subtly break access to an NTFS volume, since NTFS itself is alw…
Earlier quoted context omitted.
There are many options for case-insensitivity on Linux. The common one would be FAT, which can't handle symbolic links, so that is moot. There is also ext4 and ZFS that can have case-insensitive modes enabled (they aren't by default), which do support symbolic links. ntfs-3g also has an option to mount as case-insensitive (though said option can actually subtly break access to an NTFS volume, since NTFS itself is alw…
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.
I've actually thought about converting my whole $HOME to that way, but I do have a few files that would conflict if I did that. I honestly don't think it's that bad of an idea.
FTFY
> 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.
> 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.
Why is it meaningless? Lots of people use Git on MacOS and Windows. I'd even be willing to bet that there are more people using Git on MacOS and Windows than Linux.