Peter Murray wrote off-list:
>What about file permissions?
A copied stub will have the same permissions as the master stub. It will
be owned by whoever created the copy. Both 'ditto' and 'cp' have this
behavior.
The file permissions of a symlink are the permissions of the ultimate
referent, i.e. the master stub.
The master stub itself is owned by root and has read and execute
permissions for all, so a copy of it or a symlink to it are executable by all,
and copiable by all.
>Would it be an issue if someone without write perms to the appropriate
>app-wrapper directory was the first to run the application?
Yes it would. That's one of the "security implications" I implied here:
<http://lists.apple.com/archives/java-dev/2006/Jan/msg00367.html>
>Also, what about folks copying the app from one installed location to
>another machine - they might get the wrong flavor binary that way...
There are no "wrong flavors" for Java launchers. Either it's a universal
binary, which means it has binaries for all supported CPU architectures, or
it's PPC-only, in which case it's still covered:
<http://developer.apple.com/qa/qa2005/qa1295.html>
The only other possibility is that it's a universal binary which someone has
stripped PPC-code from, leaving only x86-code. That would be an
unsupported modification, so you should advise your customers not to do it.
If the executable is a symlink, it will still survive copying across disks,
volumes, and machines. Either the symlink itself is faithfully replicated
(a symlink-aware program does the copy), or a copy of the ultimate referent
is made, i.e. a copy of the master stub. Either way, it survives copying.
>Would it be possible to ship with a shell script that would exec the
>JavaAppStub from its home each time?
Something like this:
#!/bin/sh
exec /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub "$@"
acts the same as using a symlink, so it doesn't really give you anything
except extra complexity.
>Is there a recommended way to ship your app-bundled application?
There are several alternatives, as discussed in these message threads:
<http://lists.apple.com/archives/java-dev/2006/Jan/thrd2.html#00151>
<http://lists.apple.com/archives/java-dev/2006/Jan/thrd4.html#00345>
Without knowing what your risks, constraints, and circumstances are, the
only recommendation is to evaluate the alternatives yourself and choose the
one that seems best for you. It's all about tradeoffs: there is no one answer.
-- 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
