Hacker News Reader

Comment by mattigames | Hacker News Reader

That's also Apple's fault isn't it? App data should fall into an predictable folder regardless of the location from where is ran, if for whatever reason the app needs to use a different folder it should be something developers have to go to multiple hurdles to implement (e.g. specify in a manifest what files and where will them be stored, and explicitly specify it they should be automatically deleted or not after moving the app to the trash)

View on HN

> App data should fall into an predictable folder regardless of the location from where is ran

In fact, App Store apps are guaranteed to do that (by being in a closed sandbox); that's why Apple has an uninstallation procedure only for App Store apps.

> specify in a manifest what files and where will them be stored, and explicitly specify it they should be automatically deleted or not after moving the app to the trash

macOS tries to do that, and developers cry that macOS is becoming more and more closed. In fact, macOS already disallows all apps (including non-sandboxed apps) touching ~/Documents and ~/Downloads except for specific exceptions that the user grants.

Yeah the way they're doing this is a bit of a pain in the ass to be honest. Set up a new Mac and you have to do though tons of these popups. It causes popup fatigue and users start just clicking yes without even reading it. I've seen it many times. It defeats the purpose this way.

It reminds me very much of how they made fun of Windows Vista in the past: https://www.youtube.com/watch?v=MyGUrPxG1iM

I don't know what a better solution would be but I don't think this is it. And the documents and downloads folders are pretty arbitrary on Mac. Any user created folders don't get this protection.

I do love the way that sandboxed apps only store stuff in one folder in the ~/Library/Containers folder though. Even non-MAS apps that are sandboxed have to do that.

In fact the trick in this article doesn't even mention this, if you use it with a non-sandboxed app you're not guaranteed to uninstall everything for sure using this method.

"Would you like to allow your toaster to make toast?"

"Please grant your refrigerator permission to store milk."

You jest, but I think a kosher refrigerator that somehow prevented dairy from finding its way into the meat section would find customers.

Nonsense, is obvious that an smart artificial throat will be the final solution to this problem, it will use AI and lasers to dispose atoms of pork and non-kosher food before it reaches your stomach, automating God's will just like he intended.

> That's also Apple's fault isn't it?

Sure, but if they locked things down the way you’re proposing, people would absolutely lose their minds about the iOSification of macOS.

supporting uninstallation ≠ locking down

Supporting uninstallation by restricting applications to a sandbox that can be cleaned up == locking down

Yep.

To be fair, the situation isn't much better on Windows or Linux. While at least they have a concept of uninstalling an application, you're still reliant on the developer actually getting it right and not missing some tempfile or something.

The filesystem doesn’t have rich enough metadata about temporary files. At least Windows has a file attribute for temporary files (FILE_ATTRIBUTE_TEMPORARY), although I’m uncertain how many apps actually set it on their temporary files; Linux/Unix/etc appears to have no real equivalent. I think ideally temporary files would have rich metadata - the ID of the process, session, and application/package which created them, and some kind of retention policy and expiry date. Of course, one could always use xattrs for that, but unless they are standardised few would use them. C library functions such as mkstemp/mkdtemp/etc could be enhanced to set metadata on temporary files. The OS package manager (apt/rpm/etc) could put an xattr on an executable with the UUID of the package, and then mkstemp could copy that to an xattr of all temporary files. Now if the FS also indexed xattrs, we could upon uninstall find all temp files owned by a given package and remove them.

Many mainframe/minicomputer file systems support file expiry dates, which is an interesting feature which Unix missed.

Yeah and application bundle proplists could help with that too.

Reply on news.ycombinator.com