Re: FSCopyObjectAsync: useless and crippled
Re: FSCopyObjectAsync: useless and crippled
- Subject: Re: FSCopyObjectAsync: useless and crippled
- From: "Mark Munz (DevList)" <email@hidden>
- Date: Sun, 15 May 2005 19:59:16 -0500
On May 15, 2005, at 2:36 PM, Ondra Cada wrote:
Mark,
On 15.5.2005, at 21:24, Mark Munz (DevList) wrote:
It's also overkill for what I think are the more common case:
I want to copy file X into the /Library/ folder, getting
permission from the user if needed (just as would be the case if
you were to drag a file from your folder into /Library/.
The user should never copy anything into /Library. That's a task
for an admin, who has the appropriate rights. For user, the right
place is ~/Library.
Well OK a user probably wouldn't copy a file into Library, but an
application that needs to install files in /Library/ definitely would.
If a user DOES try to copy a file into /Library/, the finder asks if
they want to Authenticate. I don't want to require an Installer to
copy a few files into /Library/ (Apple says that's a bad user
experience and I agree), but I do think this is a common scenario
that might be solved by a simple High-Level API.
Apple wants developers to do things like "First Time Run Install" for
the best user experience. That's great, but I don't think it's asking
for much to have the Operating System offer up a little help in that
area (especially since MOST apps don't require install a kext or some
such, and instead just need to maybe copy files to area that is
privileged and requires Authentication).
The last thing I want to do is open my app to possible exploitation
because all I wanted to do was copy some files into /Library/ (and
obviously getting the users permission as part of the process)
without requiring a full-blown installer.
I know it can be done, but I don't think it is unreasonable to have a
simple API to do it (probably not file manager level, but maybe
NSWorkspace level).
Mark
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden