Jeremy Wood wrote:
>1. Go into your Library/Preferences/ folder
>2. Grab the com.companyName.ProductName.plist file for your
>application. (This file is written by the Mac OS.)
>3. Change its permission to 'No Access'
>..etc....
>Our customer reported that running "Disk Utility" to repair disk
>permission did not fix the problem.
Repair Permissions can't fix a problem if it doesn't know what to fix.
It's not omniscient.
As I understand Repair Permissions, it works by looking at the Installer's
receipts. One element in the receipts is the ownership and
access-privileges of each file installed from the Bill Of Materials (BOM).
But if you don't use Installer, or the file isn't listed in the BOM, then
the file won't be listed in a receipt, and Repair Permissions can't repair
its permissions.
>Deleting the culprit plist file does not always fix the problem. (In 1
>out of 3 scenarios it fixed the problem; I'm not exactly sure what the
>rules are regarding this.)
It could be that in the other scenarios the file is still open, and thus
its contents still exist. Unix has this notion that an open file still
exists, even when its name is deleted. I don't know if that applies here
or not, but it might.
>The best solution is to go straight to that file and restore its
>permissions. Either using the Finder or using the Terminal.
Restore the permissions to what? I'm assuming at least rw-r--r--.
>We assume this happened because of how the customer installed our
>software; probably they used Apple Remote Desktop and somehow installed
>a copy with bad permissions across a whole lab.
It could also be that the permissions were nominally correct but the owner
ID went out of scope when the file was replicated. If the original owner
from the install was Alice, and that's copied to Bob's machine, then Bob
won't own the file and may not have access unless the privilege-bits are
rw-rw-rw-.
The Cocoa-Java class NSPathUtilities can read owner and privileges on a
file, and I think also set those attributes, within the bounds of Unix's
own constraints (process must own the file or have euid-root). You'd have
to add a classpath item that points at /System/Library/Java/ but otherwise
it should be straightforward. Or you can exec() commands like ls and
chmod, or use JNI code.
>Is this a known issue?
>(I don't like filing bugs with Apple unless I have to.)
I haven't specifically heard of this before (printing death when plist is
inaccessible), but I have heard of other strange things happening when file
ownership and permissions somehow prohibited reading or writing.
The main thing I've noticed is there's no way to predict how any
application will behave or misbehave when it can't read or write its plist
file. Some of them even fail if the file is removed, because they can't
recreate a default without rerunning the program's installer.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
