![]() |
minor installation-related issues
A few observations:
* All files/directories in the SuperDuper! package are world (and group) writable. * Running the built-in updater changes the group ID of files to group staff. * The image background in the distribution package says: To install or update: Drag to Applications and run! The "Copy applications, sharing non-Apple" copy script contains: Code:
<dict> |
We made the files and directories world writable to allow for drag-and-drop update -- otherwise, you get an error when you try (and authenticating doesn't always seem to work). I'm not sure why the group is changed to staff, though: we'll take a look at that and see what we can fix.
Yes, the image does say drag to Applications (though you can put it anywhere, really -- we're trying to suggest, not insist) -- but the real problem there is the script, which shouldn't have that entry in it at all any more. We'll get rid of it. Thanks! |
Quote:
I've done all SD! installs/updates while logged in as an admin account drag-and-drop installs to /Applications work without authenticating, but the updater required authentication to run its package installer (just this morning, for the current version). Re: group staff. The bom shows files as being gid 20 (staff): Code:
% lsbom Archive.bom | head -5 Maybe drag-and-drop installs/updates and package updates with secure file/directory permissions, from admin and/or non-admin accounts, aren't possible with certain combinations. Since I've done all installs/updates from an admin account I'm not as aware of issues with them from a non-admin account. From that admin-centric install/update view I see SuperDuper! as one of the few apps on my system with world-writable permissions and it seemed ironic for backup software to be that way. |
We're going to have to re-examine exactly what we can and can't do in this situation. We tried a bunch of things that didn't work, and found the user had to delete the bundle even though they owned it, which was more than a bit weird.
Yeah, and we'll get rid of the stupid .DS_Store file, which should have automatically been done by XCode, but must not have been... |
Thanks, Dave. There are probably differences between 10.2 and 10.3 behavior to consider, too.
|
Yep, probably. It's not hugely high priority, but we'll definitely take a look next cycle.
|
All times are GMT -4. The time now is 09:38 PM. |
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.