Hacker News Reader

Comment by alin23 | Hacker News Reader

Those aren’t app files, they are user configuration files. They can’t be created inside the app bundle because the app is signed, and any modification will invalidate the signature.

There’s also the matter of permissions, some apps may be installed by the admin, but the app might not run with admin permissions for some users.

View on HN

Also having your app data stored within a bundle that (during updates) is literally just removed and replaced would lead to data loss. I don’t think there is any system that actually stores app data within/next to the binary itself.

That was quite common during the Windows 9x days, leading to that long period of time of problems later under XP with old apps only running under an admin account.

In my experience there are both a users config files and an applications support files strewn all over the place with abandon. Maybe I wasn't clear, I'm suggesting distinguishing out-of-bundle application files by making them symlinks:

> Why are an applications files physically moved elsewhere in the first place?

Application support files are still new files that get created from scratch, not moved from the application bundle.

It’s possible there’s misunderstanding in what we both consider application files. Anything that exists in the AppName.app bundle never gets modified, deleted or moved. And it’s not possible to create any new file in that bundle, not even symlinks, without invalidating the signature.

Thanks for explaining. That makes sense.

For any files that need to be modified, my suggestion would not work at all. But I'm sure there's cases developers could symlink unmodifiable files.

I know I've seen anything and everything in the users Library folder. (Application launch splash screens for example.)

Reply on news.ycombinator.com