See also: Let’s roll our own .zip implementation that only Mac can reliably read for…reasons
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
.directoryfiles with the[]spec by freedesktop.org
Dolphin has the option to enable/disable the featuretoday 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?
I don’t think the code is available for people to figure out whether there’s a reason or if it’s completely arbitrary.
Hmm… Smells like a windows user aswell… Look at that:
.desktopdesktop.iniEdit: fixed the filename
Thumbs.db
I’ve caught the whiff of some Linux too…
lost+found
you should do this with every one of these cases. btw, where does .Trash-1000 actually come from?
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
…and whoever decided a file system should be case insensitive by default, I hate you.
What’s the use case for case sensitive file names
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?
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!
In case you or others reading this don’t know: You can set bash’s tab-completion to be case-insensitive by putting
set completion-ignore-case on
Into your .inputrc (or globally /etc/inputrc)
Thank you
