if you could pick a standard format for a purpose what would it be and why?

e.g. flac for lossless audio because…

(yes you can add new categories)

summary:

  1. photos .jxl
  2. videos .av1 (someone mentioned mka or something like that, cant recall but thet mentiomed it being a ‘container’)
  3. daw session files .dawproject
  4. documents .odt
  5. archive files (this one is causing a bloodbath so i picked randomly) .tar.zst
  6. models .gltf / .glb
  7. plain text utf-8
  8. interchange format .ora
  9. configuration files toml OR yaml (disagreement)
  10. typesetting typst
  11. open domain image data .exr
  12. lossless audio .flac
  13. lossy audio .opus
  14. subtitles srt/ass
  15. container mkv
  • kadu@lemmy.world
    link
    fedilink
    arrow-up
    3
    arrow-down
    22
    ·
    edit-2
    10 months ago

    Having “double” extensions is a terrible convention for operating systems where extensions actually matter and users are used to them, like Windows.

    “.tar.xz” should be something like “.tarxz” or “.txz”

    • Longpork_afficianado@lemmy.nz
      link
      fedilink
      arrow-up
      21
      ·
      10 months ago

      But it’s not a tarxz, it’s an xz containing a tar, and you perform operations from right to left until you arrive back at the original files with whatever extensions they use.

      If I compress an exe into a zip, would you expect that to be an exezip? No, you expect it to be file.exe.zip, informing you(and your system) that this file should first be unzipped, and then should be executed.

      • kadu@lemmy.world
        link
        fedilink
        arrow-up
        1
        arrow-down
        3
        ·
        10 months ago

        it’s an xz containing a tar

        So what? When you zip 5 documents together do you name it .zip or .config.lib.sh.deb.zip?

        No, you expect it to be a file.exe.zip

        Double extensions are not conventional on Windows, so no, I do not.

        • 7eter@feddit.de
          link
          fedilink
          arrow-up
          2
          ·
          9 months ago

          Dots in filenames are commonly used in any operating system like name_version.2.4.5.exe or similar… So I don’t see a problem.

          • kadu@lemmy.world
            link
            fedilink
            arrow-up
            1
            arrow-down
            2
            ·
            9 months ago

            Dots yes, nested extensions no.

            The expected behavior is: you have a .exe binary called Example.exe. This is an executable.

            Now you zip it. It’s no longer an executable binary, it’s a zip archive. Yes, the data can be reconstructed into the original file - but it is not the original file. It should now be called Example.zip, as it is a zip file.

            This is important both for user mental models, but also because operating systems that use extensions as the primary indicator of file type often will hide known extensions by default, and the nested extensions in the name can create trouble.

      • kadu@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        9 months ago

        Cool. So it means it’s a problem for over 70% of all active desktop and laptop computers.

        • DigitalJacobin@lemmy.ml
          link
          fedilink
          English
          arrow-up
          4
          ·
          edit-2
          9 months ago

          I get the frustration, but Windows is the one that strayed from convention/standard.

          Also, i should’ve asked this earlier, but doesn’t Windows also only look at the characters following the last dot in the filename when determining the file type? If so, then this should be fine for Windows, since there’s only one canonical file extension at a time, right?

          • kadu@lemmy.world
            link
            fedilink
            arrow-up
            2
            ·
            9 months ago

            You’re absolutely correct when it comes to how Windows will interpret the file - it will ignore all the preceding “extensions” and will use the last one as the filetype and as the hook for whatever default action or application should handle it. However, getting people used to double extensions is one quick way of increasing the success rate of attacks such as the infamous “.pdf.exe” invoice from an email attachment. It also creates issues with renaming files and, though admittedly not many, some Windows application’s own file pickers.

            Still - from just a theoretical point of view, I can’t see how Windows’ convention is worse, in fact, it makes significantly more sense. If I zip a file, it doesn’t matter what it was in a previous life, it’s now a zip - this is also how Unix deals with many filetypes, I’ve never seen a .h264.mp4 file, even though the .mp4 container can actually represent different types of encoding. Why have one filetype use the Windows convention and another, for no reason, a different one?

            • DigitalJacobin@lemmy.ml
              link
              fedilink
              English
              arrow-up
              2
              ·
              9 months ago

              However, getting people used to double extensions is one quick way of increasing the success rate of attacks such as the infamous “.pdf.exe” invoice from an email attachment.

              Very good point. Though, i would argue that this would be much less of a problem if Windows stopped sometimes hiding file extensions.

              I can’t see how Windows’ convention is worse

              I don’t believe what you’re referring to is really a Windows versus Linux/Unix thing.

              If I zip a file, it doesn’t matter what it was in a previous life, it’s now a zip - this is also how Unix deals with many filetypes, I’ve never seen a .h264.mp4 file, even though the .mp4 container can actually represent different types of encoding.

              I disagree, but i do get what you’re saying here. I don’t think that example really works though, because a .mp4 file isn’t derived from a .h264 file. A .mp4 is a container that may include h264-encoded video, but it may also have a channel with Opus-encoded audio or something. It’s apples and oranges.

              Also, even though there shouldn’t be any technical issues with this on Windows, you can still use a typical short filename suffix if you wish, though i would argue that using the long filename suffix is more expressive. From “tar (computing)” on Wikipedia:

              Compressor Long Short
              bzip2 .tar.bz2 .tb2, .tbz, .tbz2, .tz2
              gzip .tar.gz .taz, .tgz
              lzip .tar.lz
              lzma .tar.lzma .tlz
              lzop .tar.lzo
              xz .tar.xz .tx
              compress .tar.Z .tZ, .taZ
              zstd .tar.zst .tzst
              • kadu@lemmy.world
                link
                fedilink
                arrow-up
                2
                ·
                9 months ago

                Though, i would argue that this would be much less of a problem if Windows stopped sometimes hiding file extensions.

                You and I are in strong agreement here, I think hidden file extensions is a super bad move.

                And as per the table you kindly included, if there’s a short single extension version of the file, I’m happy. I still don’t understand the logic behind using the long version for user-facing files, like file sharing or software distribution, but different conventions coexisting isn’t anything new in computing so it is what it is.

                • Ferk@lemmy.ml
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  edit-2
                  9 months ago

                  I think part of the reason why the long extension is often preferred is because it’s much clearer and it’s guaranteed to be supported and decompressed by the respective tools. Even when they don’t suppot tar archives, they’ll just give you the uncompressed tar in that case.

                  It’s also very common to do that with other extensions (not just .tar) when compressing big files. For example, when archiving logs they’ll often be stored as .log.gz, which makes it automatically clear that it’s a log file directly compressed with gzip and meant to be examined with tools like zcat and zless to view it.

                  And in cases like that you really need it to be clear on what data does the gzip stores, since it does not keep metadata about the file so you might not be able to get back the original name/extension of the file if you rename the gz file.

    • Gamma@programming.dev
      link
      fedilink
      English
      arrow-up
      6
      ·
      10 months ago

      I get your point. Since a .tar.zst file can be handled natively by tar, using .tzst instead does make sense.

    • sebsch@discuss.tchncs.de
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      10 months ago

      I would argue what windows does with the extensions is a bad idea. Why do you think engineers should do things in favour of these horrible decisions the most insecure OS is designed with?

      • kadu@lemmy.world
        link
        fedilink
        arrow-up
        1
        arrow-down
        2
        ·
        9 months ago

        That’s much better. Thanks for actually answering the comment, rather than the usual “Windows bad, Linux good, upvotes please”