• cm0002@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    3 months ago

    See also: Let’s roll our own .zip implementation that only Mac can reliably read for…reasons

    • stebo@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      0
      ·
      3 months ago

      every time i get a zip file from a mac user it has a folder with random junk in it. what’s up with that? i can open the files without it so clearly those files are unnecessary

      • skuzz@discuss.tchncs.de
        link
        fedilink
        arrow-up
        0
        ·
        3 months ago

        Metadata that’s a holdover from the 1980s MacOS behavior. Hilariously, today, NTFS supports that metadata better than Apple’s own filesystems of today. They can hide it in Alternate Data Streams.

          • kalleboo@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            3 months ago

            APFS still supports resource forks just fine - I can unstuff a 1990’s Mac application in Sequoia on a Apple Silicon Mac, copy it to my Synology NAS over SMB, and then access that NAS from a MacOS 9 Mac using AFP and it launches just fine.

            The Finder just doesn’t use most of it so that it gets preserved in file copies and zip files and such.

  • raspberriesareyummy@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    3 months ago

    honestly - while a Mac is certainly less painful to use than winshit, putting rubbish files recursively into each(!!) accessed folder, on all thumbdrives ever inserted, that’s something Jobs deserves to burn in hell for.

  • Lazycog@sopuli.xyz
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    3 months ago

    Hmm… Smells like a windows user aswell… Look at that:

    .desktop desktop.ini

    Edit: fixed the filename

  • webghost0101@sopuli.xyz
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    3 months ago

    I would also like a word with “bonjour” process while we’re at it.

    Thought it was a virus when I first discovered it.

      • Takumidesh@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        3 months ago

        Well an uppercase ASCII char is a different char than its lowercase counterpart. I would argue that not differentiating between them is an arbitrary rule that doesn’t make any sense, and in many cases, is more computationally difficult as it involves more comparisons and string manipulations (converting everything to lower case).

        And the result is that you ultimately get files with visually distinct names, that aren’t actually treated as distinct, and so there is a disconnect from how we process information and how the computer is doing it.

        ‘A’ != ‘a’, they are just as unequal as ‘a’ and ‘b’

        Edit: I would say the use case is exactly the same as programming case sensitivity, characters have meaning and capitalizing them has intent. Casing strategies are immensely prevalent in programming and carry a lot of weight for identifying programmers’ intent (properties vs backing fields as an example) similar intent can be shown with file names.

      • Speiser0@feddit.org
        link
        fedilink
        arrow-up
        0
        ·
        3 months ago

        Think the other way around: What’s the use case for case insensitive file names? Does it justify the effort and complexity for the filesystem and the programs to know the difference between lower and upper space chars?

        • mindbleach@sh.itjust.works
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          3 months ago

          What’s the use case for case insensitive file names?

          Human comprehension.

          Readme, readme, README, and ReadMe are not meaningfully different to the average user.

          And for dorks like us - oh my god, tab completion, you know I mean Documents, just take the fucking d!

  • FQQD! @lemmy.ohaa.xyz
    link
    fedilink
    arrow-up
    0
    ·
    3 months ago

    you should do this with every one of these cases. btw, where does .Trash-1000 actually come from?

    • Lucy :3@feddit.org
      link
      fedilink
      arrow-up
      1
      ·
      3 months ago

      I had a long and frustrating conflict with this, on this post.

      As @[email protected] (An dem Punkt könnten wir auch einfach Deutsch labern) noted, it’s a freedesktop.org specification.

      I still stand the point that it’s not very thought through (a hidden dir? Why?), and that blindly implementing it is annoying. It shouldn’t be a universal standard for all systems, as it’s only relevant if you use a file manager which can then use that dir as Trash dir - which I don’t. That could be tested by only allowing filemanagers to create the dir, and if it doesn’t exist, discard the data. That’s probably how some programs work, as only Prismlauncher has created the dir.

      Workaround: ln -s .Trash-1000 /dev/null

  • boonhet@lemm.ee
    link
    fedilink
    arrow-up
    0
    ·
    3 months ago

    Just gitignore that. Same for dot idea and whatever vscode adds, if anything

    • andioop@programming.dev
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      3 months ago

      git add . > git commit -m "initial" > git push

      Later when I git status or just look at the repo online… “oh crap I let .DS_Store in didn’t I…” and then I remember to set up a .gitignore and make a new commit to take out the .DS_Store and put in the .gitignore.

      • PartiallyApplied@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        3 months ago

        You probably already know this, but for those who don’t, git can globally ignore patterns. It’s the first thing I set up after logging in. Honestly wish git just shipped this way out of the box (maybe match .DS_Store by name and some magic bytes?) with a way to disable it. Just for the sake of easier onboarding