Love it.
Too bad there aren't enough Mac users to prompt a similar backlash against Macs littering every computer they visit on the network with .DS_Store and other turds.
Too bad there aren't enough Mac users to prompt a similar backlash against Macs littering every computer they visit on the network with .DS_Store and other turds.
The problem is that virus scanners sometimes misclassify those temp files as belonging to malware apps, or sometimes they might be written by real malware apps, but even in the latter case, that only happens because the malware uses sqlite as a library. The malware isn't written by the SQLite authors, so complaining to them is pointless.
.DS_Store files come from Apple's file systems containing a separate data and resource fork. APFS can natively store the contents, but for foreign file systems/network shares, a .DS_Store file is created to store those attributes.
`.gitignore` is for stuff that all developers need to ignore, like compiler output, and should be kept to the bare minimum.
But that is the case, all developers need to ignore the ".DS_Store" files. So by your own rule it is appropriate in there then?
Global .gitignore exists, but I just had to look it up again to refresh my memory – chances are, junior devs or hobby developers will never even consider it as an option.
That said, arguably ignoring .DS_Storage should be the default on macOS builds of git.
I can do the principled thing as you describe it. And then I can be angry every time a new dev arrives who doesn't have their computer correctly set up yet, or someone reinstalls their machine, or anything like that.
Or I can do the pragmatic thing, add one extra line to the .gitignore file and forget about it forever.
In my opinion this is not a hill worth dying on.
And, for what it's worth, all developers need to ignore .DS_Store files regardless if Finder creates it or it gets placed in when you unzip something created on a Mac, for instance.
In the best case, you spend extra time needlessly denying PRs and bothering people who already likely don't know git well enough to cleanly fix their commit. In the case of a repo large enough that you're not the only person approving PRs, I'd say it's almost inevitable that they eventually slip through.
Just my 2¢ from experience working in the industry.
No, that would be ._<filename> files (containing resource forks, when the corresponding file is stored on a volume with a FS not supporting them natively), which are much rarer these days given that resource forks are not really used anymore.
.DS_Store contains Finder metadata, as far as I know (non-default icon sorting or positioning, categories, tags etc.), and they occur on all volumes, including Mac native filesystems. Finder just hides them by default.
Firstly, it not that anti-virus software was misclassifying it -- it's that a particular one, Mcafee, was USING sqlite. And more importantly, it didn't put the file(s) in the proper %temp% folder. Instead, it created it as `C:\temp\{name}.sqlite_`. This is why users found them suspicious and complained to devs.
Also keep in mind putting random files or folders under root of C:\ was, while never recommended, a common practice in 2000s (some still do so even today). So what Mcafee was doing is hardly unheard of. But people still freak out when they see these in their C:\ (TBH, understandable).
> %userprofile%
Apple, in its arrogance and backwardness, doesn't store those choices on the BROWSING user's computer; it stores them in the directories on the computer being browsed... where, by the way, they'll be trounced by the next Finder user who comes along.
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true
defaults write com.apple.desktopservices DSDontWriteUSBStores -bool trueMy other favorite Apple filesystem cock-up is the inclusion of a "Contents" directory in every bundle, which never has any siblings. I mean... what kind of ass thinks that a directory needs a subdirectory to hold the contents of itself?
The one thing Apple fixed in Finder that annoyed the living #$%! out of me for all previous years was that you couldn't sort files WITH FOLDERS AT THE TOP. Of course the fix was incomplete, broken in some places at first, including your Desktop directory. But that did get fixed surprisingly quickly.
desktop.ini