• @radamant
    link
    English
    2610 days ago

    Windows way is superior, in my opinion. I don’t think there’s a need for File.txt and fILE.txt

    • @[email protected]
      link
      fedilink
      17
      edit-2
      10 days ago

      Indeed. Linux audio also allows control characters like backspace to be part of a file name (though it is harder to make such file as you can’t just type the name). Which is just horrible.

        • clif
          link
          210 days ago

          Yeah, Linux can capture and playback the spoken distinction between lowercase and uppercase letters. Windows can’t do that.

          You’re not taking advantage of that functionality?

          • @TrickDacy
            link
            310 days ago

            I sense sarcasm but I don’t really get it. I still can’t tell if the OC had a typo or not :)

            • clif
              link
              310 days ago

              : D

              I think they just fixed it

              • @TrickDacy
                link
                310 days ago

                I was so curious if there was some weird Linux audio system I didn’t begin to understand lol

                It sounded plausible kind of because every device is mapped to a file path somewhere!

    • DefederateLemmyMl
      link
      fedilink
      1110 days ago

      I don’t think there’s a need for File.txt and fILE.txt

      It’s not so much about that need. It’s about it being programmatically correct. f and F are not the same ASCII or UTF-8 character, so why would a file system treat them the same?

      Having a direct char type to filename mapping, without unnecessary hocus pocus in between, is the simple and elegant solution.

      • @Serinus
        link
        710 days ago

        It turns out that the easiest thing to program isn’t always the best application design.

        • DefederateLemmyMl
          link
          fedilink
          English
          1
          edit-2
          10 days ago

          I would argue that elegance and being easy to program are virtues by themselves, because it makes code easy to understand and easy to maintain.

          A one-to-one string to filename mapping is straightforward and elegant. It’s easy to understand (“a filename is a unique string of characters”), it makes file name comparisons easy (a bit level compare suffices) and as long as you consistently use the case that you intend, it doesn’t behave unexpectedly. It really is the way of the least surprise.

          After all, case often does have meaning, so why shouldn’t it be treated as a meaningful part of a filename? For example: “French fries.jpg” could contain a picture of fries specifically made in France, whereas “french fries.jpg” could contain a picture of fries made anywhere. Or “November rain.mp3” could be the sound of rain falling in the month of November, whereas “November Rain.mp3” is a Guns N’ Roses song. All silly examples of course, but they’re merely to demonstrate that capitalization does have meaning, and so we should be able to express that canonically in filenames as well.

          • @redisdead
            link
            08 days ago

            It’s not elegant when it causes more problems than it solves.

        • DefederateLemmyMl
          link
          fedilink
          4
          edit-2
          10 days ago

          Because it’s designed for average people

          It is not. It is designed for all purposes, automated processes and people alike. A filesystem is not just for grandma’s Word documents.

          And even people’s names are case sensitive. My name has the format Aaa Bbb ccc Ddd. It is not the same as the person with the name Aaa Bbb Ccc Ddd, who also exists. So why shouldn’t file names be?

            • DefederateLemmyMl
              link
              fedilink
              English
              1
              edit-2
              10 days ago

              give me one use case where it makes sense having several files with the same name but different cases in the same directory

              Imagine a table in a database where the primary key is a case sensitive character field, because you know varchars, just like C char types and string types in other languages are case sensitive.

              Imagine a database administrator does the following:

              • Export all data with primary key = ‘Abcde’ to ‘Abcde.csv’

              Imagine a second database adminstrator around the same time does the following:

              • Export all data with primary key = ‘abcde’ to ‘abcde.csv’

              Now imagine this is the GDPR data of two different users.

              If you have a case insensitive file system, you’ve just overwritten something you shouldn’t have and possibly even leaked confidential data.

              If you have a case sensitive file system you don’t have to account for this scenario. If the PK is unique, the filename will be unique, end of story.

              • @[email protected]
                link
                fedilink
                English
                010 days ago

                If you don’t do something stupid like reuse keys just with different capitalization, this never occurs.

                • DefederateLemmyMl
                  link
                  fedilink
                  English
                  510 days ago

                  The point is you have to take this into account, so the decision to go with a case insensitive file system has ripple effects much further down your system. You have to design around it at every step in code where a string variable results in a file being written to or read from.

                  It’s much more elegant if you can simply assume that a particular string will 1-on-1 match with a unique filename.

                  Even Microsoft understands this btw, their Azure Blob Storage system is case sensitive. The only reason NTFS isn’t (by default) is because of legacy. It had to be compatible with all uppercase 8.3 filenames from DOS/FAT16.

      • @radamant
        link
        English
        09 days ago

        That’s some suckless level cope. What’s correct is the way that creates the least friction for the end users. Who really cares about some programming purity aspect?

        • DefederateLemmyMl
          link
          fedilink
          English
          1
          edit-2
          9 days ago

          That’s some suckless level cope

          Thanks, really constructive way of arguing your point…

          Who really cares about some programming purity aspect?

          People who create operating systems and file systems, or programs that interface with those should, because behind every computing aspect is still a physical reality of how that data is structured and stored.

          What’s correct is the way that creates the least friction for the end users

          Treating different characters as different characters is objectively the most correct and predictable way. Case has meaning, both in natural language as well as in almost anything computer related, so users should be allowed to express case canonically in filenames as well. If you were never exposed to a case insensitive filesystem first, you would find case sensitive the most natural way. Give end users some credit, it’s really not rocket science to understand that f and F are not the same, most people handle this “mindblowing” concept just fine.

          Also the reason Microsoft made NTFS case insensitive by default was not because of “user friction” but because of backwards compatibility with MSDOS FAT16 all upper case 8.3 file names. However, when they created a new file system for the cloud, Azure Blob Storage, guess what: they made it case sensitive.