Re: "First Run" installation of Application support stuff?
Re: "First Run" installation of Application support stuff?
- Subject: Re: "First Run" installation of Application support stuff?
- From: Bill Bumgarner <email@hidden>
- Date: Wed, 18 Dec 2002 14:26:26 -0500
On Tuesday, Dec 17, 2002, at 16:11 US/Eastern,
email@hidden wrote:
Its not a big deal to update a pref file residing in the app folder
from
within your app. If a user moves the pref file out of the app folder,
a new
one will be created and the old prefs are lost, but that is no
different for
prefs in the pref folder.
I have to chime in here...
Do not ever, under any circumstances, for any reason, store prefs in
the app folder. It is a bad, bad idea no matter what way you look at
it. It is just lazy. There are places to store writable stuff that
are well documented and well convered in this thread. In the app
wrapper is NOT ONE OF THEM.
It is wrong for so many reasons, let me list a few. Assuming writable
prefs (or any other data) in the app wrapper, then:
- backups have to back up the entire application. Inconvenient: I
either have to know and back up just the apps that store data in their
app wrapper OR I have to backup my entire Applications directory-- all
umpteen hundreds of megabytes of data that otherwise very rarely
changes and is often easier to just download off the net.
- it hoses security; the app has to be writable by the user's
account and, therefore, can be trivially corrupted or infected
- it makes upgrading the app a pain in the ass; i can't just drag
and drop to replace it.
- it makes shipping upgrades a pain in the ass; the developer has
to explicitly add support for the writable data in the app wrapper or
risk losing customer data
- makes it impossible to stick the app on read only media such as
disk images, CDR, or network mount points.
- it eliminates potential filesystem optimizations; a read-only
filesystem can be assumed to be constant, thereby making operations
such as memory mapping and operation caching potentially a bunch more
expensive
--
There is a disturbing trend in the mac community of requiring root
privileges for installations when it is unnecessary, requiring reboots
when it is unwarranted, requiring admin access just to run the app, and
requiring write access to the app wrapper and other locations on disk
that should not be.
The justification is often "it is the user's computer they should do
what they want".
To put it bluntly: Bullhorkie.
There is a very good reason to restrict access rights-- including
administrative/root access and write access-- on the system as much as
possible. It prevents nefarious code-- virii and crap code-- from
doing any significant damage to the system. It also makes it possible
to share applications across multiple users of the same machine while
the user experience remains consistent-- when I use my sister's
machine, I don't want to have to go hunting for freakin' TextEdit
because she thought it should be called Pencil Power and should reside
in Documents (if she wants to do that, fine, create a stupid alias!)
Limiting the rights of the user increases security, decreases system
fragility, decreases risks during updating, increases data reliability,
increases convenience related to backing up data, and otherwise
generally improves the user experience.
Direct example: If you *follow* Apple's lead and put the prefs and
other writable resources for an application in the defaults database
and ~/Library/Application Support/ *as you should*, then an App like
BackUp will *automatically* backup the volatile data related to the app
in its default configuration-- the one that most users's will use AND
it will do so without duplicating megabyte upon megabyte relatively
static data [the app executable].
Continuing down this path of wanting to scribble everywhere because it
is the Macintosh Way will lead to an Operating System that is no better
than Windows; plenty of virii that cause piles of damage along with a
system that has to be rebuilt every 3 months just to remain stable.
That is not the Macintosh Way.
b.bum
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.