6 ms·
> That's how it should be Why? Windows is also not case-sensitive, so it's not like there's a near-universal convention that S3 is ignoring. Case sensitivity
by smt88 2y ago
> That's how it should be
Why? Windows is also not case-sensitive, so it's not like there's a near-universal convention that S3 is ignoring.
Case sensitivity in file names is surprising even to non-technical people. If someone says they sent you "Book Draft 1.docx" and you check your email to find "Book draft 1.docx," you don't say, "Hey! I think you sent me the wrong file!"
Casing is usually not meaningful even in written language. "Hi, how are you?" means the same thing as "hi, how are you?" Uppercase changes meaning only when distinguishing between proper and common nouns, which is rarely a concern we have with file names anyway.
- josephcsible 2y ago> If someone says they sent you "Book Draft 1.docx" and you check your email to find "Book draft 1.docx," you don't say, "Hey! I think you sent me the wrong file!" But you also wouldn't say that if they sent "Book - Draft 1.docx", "Book Draft I.docx", "BookDraft1.docx", "Book_Draft_1.docx", or "Book Draft 1.doc", and surely you wouldn't want a filesystem to treat all of them as the same.
- atkailash 2y ago[dead]
- cmcconomy 2y agoyou called it - those are different situations all right
- quickslowdown 2y agoThis is a personal reason, but the reason I prefer case sensitive directory names is I can make "logical groupings" for things. So, my python git directory might have "Projects/" and "Packages/," and the capitalization not only makes them stand out as a sort of "root path" for whatever's underneath, but the capitalization makes me conscious of the commands I'm typing with that path. I can't just autopilot a path name, I have to consciously hit shift when tab completion stops working. That might sound like a dumb reason, but it's kept me from moving things into the wrong directory, or accidentally removing a directory multiple times in the past. I also use Windows regularly and it really isn't a hindrance, so maybe I wouldn't actually be bothered if everything was case sensitive.
- pwagland 2y agoTBF, you don't need case sensitive FS for that, just case retaining is enough. And then have the option on how to sort it.
- josephcsible 2y agoDon't you need case sensitivity for this part? > I can't just autopilot a path name, I have to consciously hit shift when tab completion stops working. On a system that's case retaining but not case sensitive, wouldn't "pr" autocomplete to "Projects"?
- zoky 2y agoNo, MacOS doesn’t do that. `cat Foo` and `cat foo` will both work, but only the first one will tab complete if the file is called `Foo`.
- chuckadams 2y agozsh tab-completed both just fine, preserving the case in both. I’d have preferred it corrected the case, but meh.
- notjoemama 2y agoI like it! That's a great idea. To me, this sounds like a great practice for terminal environments but may be less intuitive when using file system apps. I could easily overlook a single letter capitalization in a GUI view of many directories. Maybe it's because at a terminal the "view" into the file system is narrow? Now I'm wondering how I can use this in my docker images. I mean that might irritate devops. Well, maybe they'll like it too. Man, thanks for posting this.
- stronglikedan 2y agoCapitalization isn't part of grammar. Those examples are different strings of characters altogether.
- otteromkram 2y agoI'll augment your statement by noting that punctuation is also not part of grammar.
- selenography 2y agoAnother classic counterexample: "This book is dedicated to my parents, Ayn Rand, and God." "This book is dedicated to my parents, Ayn Rand and God."
- selenography 2y agoThe classic, if crude, counterexample: "I helped my uncle Jack off a horse." (The uncapitalized version doesn't just have different semantics; it has a completely different parse-tree!)
- ooterness 2y agoYou have to draw the line somewhere, but I do appreciate when the UI sorts "Book draft 2" before "Book draft 11". That requires nontrivial tokenization logic and inference, but simple heuristics can be right often enough to be useful. On that note, ASCIIbetical sort is never the right answer. There is a special place in hell for any human-facing UI that sorts "Zook draft 1" between "Book draft 1" and "book draft 1".
- yencabulator 2y agoAnd that line, at least for sorting, belongs firmly outside the filesystem. Sorting is locale-dependent. Whether a letter-with-dots sorts next to letter-without-dots or somewhere completely different has no correct global answer.
- saghm 2y agoI think there's a pretty big difference between how the UI orders things and how the filesystem treats things as equivalent. A filesystem treating names case sensitively doesn't prevent the UI from tokenizing the names in any other arbitrary way
- pkulak 2y agoYeah, but that little bit of user friendliness ruins the file system for file system things. Now you need “registries” and other, secondary file systems to do file system things because you can’t even use base64 in file names. Make your file browsing app case insensitive, if that’s what you want. Don’t build inferiority down to the core.
- lultimouomo 2y agoCase insensitive matching is a surprisingly complicated, locale-dependent affair. Should I.txt and i.txt match? (Note that the first file is not named I.txt). Case insensitive filesystems make about as much sense as ASCII-only filenames.
- HeatrayEnjoyer 2y agoHow would locale matter?
- GolDDranks 2y agoFor example, it depends on the locale if the capitalized form of ß is ß or SS.
- ckolkey 2y agoOff the top of my head, in turkish, `i` doesn't become `I`, it becomes `İ`. And `ı` is the lower case version of `I`
- Dylan16807 2y agoYou don't need to decide how to upper or lower case a character to be insensitive to case, though. Treating them all as matching isn't a terrible option.
- jodrellblank 2y agoAnd yet case insensitive file name matching / string matching is one of my favourite windows features. It’s enormously convenient. An order of magnitude more convenient than the edge cases it causes me. People aren’t ASCII or UTF-8 machines; “e” and “E” are the same character, that they are different ASCII codes is a behind the scenes implementation detail. (That said, S3 isn’t a filesystem, it’s more like a web hashtable key-to-blob storage)
- lultimouomo 2y ago> People aren’t ASCII or UTF-8 machines; “e” and “E” are the same character They are the same character to you, a native speaker of a Western language written in a latin script. They are the same to you because you are, in fact, an ASCII machine. Many many people in the world are not.
- fortran77 2y ago> Why? Windows is also not case-sensitive, so it's not like there's a near-universal convention that S3 is ignoring. You can enable case sensitivity for directories or disks, but this is usually done for special cases, like git repos
- blahgeek 2y agoNo offense, but I think that's a very western-centric view. Your example only make sense when the user is familiar to English (or other western languages, I guess). To me personally, I find it strange that "D.txt" and "d.txt" means the same file, since they are two very different characters. Likewise, I think you would also go crazy if I tell you "ア.txt" and "あ.txt" means the same file (which is hiragana and katakana for A respectively, which in a sense is equivalent to uppercase and lowercase in Japanese), or "一.txt" and "壹.txt" means the same file (which both means number 1 in Chinese, we call the latter one literally "uppercase number")
- ClumsyPilot 2y agoThose are all the same, I don’t see an issue
- n_plus_1_acc 2y agoWhat if Unicode updates some capitalization rules in the next version, and after an OS updates some filenames now collide and one of the is inaccessible?
- taeric 2y agoAgreed, and you could even take this into "1.txt" being the same as "One.txt". Which, I mean, fair that I would expect a speech system to find either if I speak "One dot t x t". But, it would also find "Won.txt" and trying to bridge the phonetic to the symbolic is going to be obviously fraught with trouble.
- JohnFen 2y ago> To me personally, I find it strange that "D.txt" and "d.txt" means the same file, since they are two very different characters. As a native English speaker, I agree with this.
- re-thc 2y ago> you don't say, "Hey! I think you sent me the wrong file!" You do! Why not? It's a big trap. A lot of counterfeit, spam, phishing etc go by this method. You end up buying a fake brand or getting tricked.
- up2isomorphism 2y agoThen why don’t you just always write in lower case?
- raincole 2y ago> Casing is usually not meaningful even in written language. "Hi, how are you?" means the same thing as "hi, how are you?" Uppercase changes meaning only when distinguishing between proper and common nouns, which is rarely a concern we have with file names anyway. The number of spaces is usually not meaningful in written language. "Hi, how are you?" means the same thing as "Hi, how are you ?". I don't think it's a good reason to make file system ignore space characters.
- Lutger 2y agoThere are just not the same characters. A filesystem should not have an opinion on what strings of characters _mean_ the same. It is the wrong level of abstraction. filenames might even not be words at all, and surely not limited to English. We shouldn't implement rules and conventions from spoken English at a filesystem level, certainly not S3. MacOS and Windows are just wrong about this.
- frizlab 2y agoAnd so should we be able to have “é.txt” and “é.txt” in the same directory (with a different UTF-8 normalization?) What encoding should we use BTW? I’m not advocating for case-insensitive fs (literally the first thing I do when I get a Mac is reformat it to be on a case-sensitive fs), but things are not that simple either.
- marcosdumay 2y ago> And so should we be able to have “é.txt” and “é.txt” in the same directory That's what Linux does. It does create some problems that seem to never happen on practice, while it avoids some problems that seem to happen once in a while. So yeah, I'd say it's a good idea.
- ozim 2y agoYou look from technical perspective. From average person perspective, even files are too much technicality to deal with. As a user I want my work to be preserved, I want to view my photos and I want system to know where is my funny foto of my dog I did last Christmas. As a developer I need an identifier for a resource and I am not going to let user decide on the Id of the resource, I put files in system as GUID and keep whatever user feels as metadata. Exposing average people to the filesystem is wrong level of abstraction. That is why iOS and Android apps are going that way - but as I myself am used to dealing with files it annoys me that I cannot have that level of control, but I accept that I am quite technical.
- graemep 2y agoDealing with files used to be something everyone interacting with computers had to do. It is something average people can do. I think too much abstraction is a mistake and adds a lot of unneeded complexity. People should learn something about technology they use. If you want to drive, you need understand how steering wheels work, if you want to drive a manual car (usual where I live and have lived) then you need to know how to work a gear stick and the effect of changing gear.
- zarzavat 2y agoFile systems are not user interfaces. They are interfaces between programs and storage. Case insensitive is much better for programs. The user shell can choose however it wants to handle file names, a case sensitive file system does not prevent the shell from handling file names case insensitively.
- zarzavat 2y ago> case insensitive is much better for programs Can’t edit my comment. I mean case sensitive is better for programs, of course.
- sergeykish 2y agoIf someone says they sent you "Book Draft 1.docx" and you check your email to find "Ⓑⓞⓞⓚ Ⓓⓡⓐⓕⓣ ①.ⓓⓞⓒⓧ", "฿ØØ₭ ĐⱤ₳₣₮ 1.ĐØ₵Ӿ" - these are different files.
- throwaway211 2y agoI have a feeling you enjoyed that character set lookup. I know I did seeing it.
- Izkata 2y agoAges ago on Flowdock at work (a chat webapp kind of like Slack that no longer exists), I used the circle ones for a short time as my nickname, and no one could @ me.
- koolba 2y ago> Casing is usually not meaningful even in written language. "Hi, how are you?" How about: “pay bill” vs “pay Bill”? “Usually” in the context of automated systems design is a recipe for disaster. Computers store bytes, not characters that may just happen to mean similar things. Shall we merge ümlauts? How to handle ß?
- lathiat 2y agoCase Preserving and Case Sensitive are subtly two different things. Most case insensitive file systems are case preserving and whatever the UTF8 equivalent is I forget the name.
- nostrebored 2y agoBut the gps point is that assuming you know the semantic meaning of the case and if retention is enough is silly. Assuming case insensitivity is bizarre.
- mdaniel 2y agoheh, I especially enjoy that in a huge thread about how capitalization does and doesn't matter, "gps point" was not, in fact, concerning some coordinates of the global positioning system but rather "GP's point". I first chalked it up to some autocomplete artifact but then realized what was actually happening
- ooterness 2y agoPerfect is the enemy of good. It is quite acceptable to streamline the easy cases now and the hard cases later or never.
- paulddraper 2y ago> Why? Because it introduces extra complexity. Now, "Cache" and "cache" are the same, but also...different because you'd care if Cache suddenly became cache.
- rzwitserloot 2y agoAlso note that 'are these 2 words case insensitively equal' is impossible without knowing what locale rules to apply. And given that people's personal names tend to have the property that any locale rules that must be applied are _the locale that their name originates from_, and that no repository of names I am aware of stores locale along with the name, that means what you want, is impossible. In line with case insensitivity, do you think `müller` and `muller` should boil down to for example the same username for login purposes? That's... tricky. In german, the standard way to transliterate names to strict ASCII would be to turn `müller` into `mueller`. In swiss german that is in fact mandatory. Nobody in switserland is named `müller` but you'll find loads of `mueller`s. Except.. there _are_ `müller` in switzerland - probably german citizens living ther. So, just normalize `ü` to `ue`, easy, right? Except that one doesn't reverse all that well, but that's probably allright. But - no. In other locales, the asciification of `ü` is not `ue`. For example, `Sjögren` is swedish and that transliterates to `sjogren`, not `sjoegren`. Bringing it back to casing: Given the string `IJSSELMEER`, if I want to title case that, the correct output is presumably `IJsselmeer`. Yes, that's an intentional capital I capital J. Because it's a dutch word and that's how it goes. In an optimal world, there is a separate unicode glyph for the dutch IJ as a single letter so we can stick with the simple rule of 'to title case a string, upper case the first glyph and lowercase all others, until you see a space glyph, in which case, uppercase the next'. But the dutch were using computers fairly early on and went with using the I and the J (plain ascii) for this stuff. And then we get into well trodden ground: In turkish, there is both a dotted and a dotless i. For... reasons they use plain jane ascii `i` for lowercase dotted i and plain jane ascii `I` for uppercase dotless I. But they have fancy non-ascii unicode glyphs for 'dotted capital I' and 'dotless lowercase i'. So, __in turkish__, `IZMIR` is not case-insensitive equal to `izmir`. Instead, `İZMIR` and `izmir` are equal. I don't know how to solve this without either bringing in hard AI (as in, a system that recognizes 'müller' as a common german surname and treats it as equal to 'mueller', but it would not treat `xyzmü` equal to `xyzmue` - and treats IZMIR as not equal to izmir, because it recognizes it as the name of a major turkish city and thus applies turkish locale rules), or decreeing to the internet: "get lost with your fancypants non-US/UKian weird word stuff. Fix your language or something" - which, well, most cultures aren't going to like. 'files are case insensitive' sidesteps alllllll of this.
- JohnFen 2y ago> Why? Windows is also not case-sensitive, so it's not like there's a near-universal convention that S3 is ignoring. Not sure why what Windows does is relevant to this, honestly. Personally, I strongly prefer case sensitivity with filenames, but the lack of it isn't a dealbreaker or anything.
- CamperBob2 2y agoWhat are some of the advantages of case sensitivity? Are you saying you actually want to save "Book draft 1.docx" and "Book Draft 1.docx" as two separate files? That just sounds like asking for trouble.
- JohnFen 2y agoThe advantages that I value are that case sensitivity means I can use shorter filenames, it makes it easier to generate programmatic filenames, and I can use case to help in organizing my files. > Are you saying you actually want to save "Book draft 1.docx" and "Book Draft 1.docx" as two separate files? That's a situation where sensitivity can cause difficulty, yes, but for me personally, that's a minor confusion that is easy to avoid or correct. Everything is a tradeoff, and for me, putting up with that annoyance is well worth the benefits of case sensitivity. I do totally understand that others will have different tradeoffs that fit them better. I'm not taking away from that at all. But saying "case sensitivity is undesirable" in a broad sense is no more accurate than saying "case sensitivity is desirable" in a broad sense. Personally, I think the ideal tradeoff is for the filesystem to be case sensitive, but have the user interfaces to that file system be able to make everything behave as case-insensitive if that's what the user prefers.
- Dylan16807 2y agoEven with only one case, just four characters is enough for a million files. How much benefit are you really getting from case sensitivity?
- marssaxman 2y ago