> This vulnerability affects platforms with case-insensitive filesystems...
What kind of platforms use case-insensitive filesystems?
What kind of platforms use case-insensitive filesystems?
https://www.collabora.com/news-and-blog/blog/2020/08/27/usin...
Note: I also learned this today. Had no clue.
What idiot would name files like that? I said.
You, they answered.
I don't do that sort of thing anymore.
A related bug is a developer will make a webpage called /a/ but link to /A/ and then the link will be broken in production. At this point, I have seen this same bug enough times to be able to fix it reasonably quickly, but it definitely wastes time for the team.
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.
EDIT: This document describes some of the challenges: https://www.usenix.org/legacy/publications/library/proceedin...
Nah. Using a file system means putting up with its semantics. HFS+ was case-insensitive; they were deploying an upgrade to millions of existing filesystems.
If you mount, say, an NFS volume, MacOS does the expected thing.
IIRC, one place where it does rear its head in when a file is renamed in a git commit to a value that downcases to the same value as the prior name. For example `Foo.txt`->`foo.txt`.
I have `core.ignorecase = true` in my `.gitconfig` for this very reason.
The Linux kernel is one of them: several of the headers that get installed to /usr/include/linux/netfilter have conflicts on a case-insensitive filesystem. https://github.com/torvalds/linux/tree/master/include/uapi/l...
Debhelper used to be one of those until I convinced them to change it: they had a Debian/ directory for the Perl module Debian::Debhelper as well as a debian/ directory for the packaging metadata. https://bugs.debian.org/873043
(I suspect I'm a little unusual in wanting to have checkouts of Linux and Debhelper on my Mac homedir.)
Why would you introduce complexity into the filesystem to try to normalize file names when you can simply, not? I mean, have you _seen_ the mess that is Unicode normalization? Hundreds of different glyphs or whatever that are all considered equivalent, but are actually composed of different bytes. The filesystem should try to make sense of all that, and consider them equivalent paths?
Even if you say "well, just capitalization, not Unicode normalization," there's the whole German letter ẞ => ss (or is it ß?) and similar friends like the Turkish dotted I that have popped up as articles on HN. Absolutely glad Linux filesystems by and large do not attempt to take that on, and treat paths as a bucket of bytes instead.
All for what benefit - so you can type File.txt in the terminal and have the OS find file.txt? That is much more appropriate for the Application layer to resolve, rather than the filesystem.
Bugs like this come from over-engineering. Filesystems should be simple, and follow the principle of least surprise.
Wait I'll try
...nope, after `touch makefile` and `touch Makefile`, I still see just `makefile`. OK
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.
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.
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.
This has mostly been useful for working on shared repositories where, say, a Linux user (or other user on a case-sensitive filesystem) pushes two branches, say `feature/foo` and `feature/Foo` which works fine for them, but on a case-insensitive filesystem, git gets very upset.
Leaky abstractions all the way down.
Its a notable problem with git + Windows that has gotten better over time but still leads to a lot of WTF moments. For many this event is the first time they hear that window's filesystem is case insensitive.