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.
You’d want that, but a lot of programs do that, both in Windows and Linux.
e.g. The .directory files with the [Desktop Entry] spec by freedesktop.org
Dolphin has the option to enable/disable the feature
FWIW Dolphin only does it if the filesystem doesn’t provide a way to add that metadata directly to the directory and you change the view configuration for that directory away from your standard configuration. Which is how the standard describes to do it. (Some file managers incorrectly add those .directory files to every directory you visit.)
A mac will add a .DS_Store file to any directory just by breathing on it.
today I learned - using Linux at home since 2005ish and I have never had an auto-file generated on any USB attached drives of mine…
I am not familiar with MacOS, but that seems like a nightmare. What is the purpose of these files?
the macos file browser, Finder, lets you set a background for a folder, move file icons around to arbitrary positions, other shenanigans. in order for this to work across systems on removable storage media and network mounts, they have this.
Why not make the file when a change is made like with windows desktop.ini files?
Is there a valid reason not to store that [[anywhere else]], ideally in Spotlight’s data?
See also: Let’s roll our own .zip implementation that only Mac can reliably read for…reasons
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
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.
Hmm… Smells like a windows user aswell… Look at that:
.desktop desktop.ini
Edit: fixed the filename
Thumbs.db
you should do this with every one of these cases. btw, where does .Trash-1000 actually come from?
Freedesktop.org’s trash specification. It’s where files moved to trash go before being deleted when it’s emptied. The 1000 is the user id.
I had a long and frustrating conflict with this, on this post.
As @d_k_bo@feddit.org (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
I agree. It somehow seems very unfinished, and it annoyed me more than I’d like
