It would be interesting to note what entries you have in
your .plist which might identify how ALF is currently interpreting
your app. It may be possible to reverse-engineer the logic from
there, but since I've never used ALF I don't know anything more
specific.
This is exactly why I'd like to use the well-documented ipfw. ;-) I
did have a look to see how my java application may be represented
but didn't find out
I hope I'm not get off topic here? When I use the java application
Vuze.app (a bittorrent client) the alf allow/deny dialog pops up. When
the application is started it takes some time until it has finnished
loaded everything it needs until it reach an operational state. The
alf dialog pops up during the load, before it has finished loading.
Now to the point: sometimes the allow/deny generated is for java.app
(not really sure if the '.app' is correct) and sometimes it is for the
more expected Vuze.app. I can't rule out that alf sometimes acctually
pops up 2 allow/deny dialogs, one for Vuze respectively one for java!?
However both dialogs regardles of if they originates from the same app
load or not can result in one permanent setting each.
This have bugged me a bit since I've wondered what the more generic
named java rule does that the Vuze.app rule is not, if anything? Is it
as generic in function as it name implies?
I've have taken the lazy (could have searched for info about it) but
safe act of deleting the java rule and do not allow it anymore ending
up with only one rule, the 'allow Vuze.app'. It does the job for me.
// John Stalberg
_______________________________________________
MacOSX-admin mailing list
[email protected]
http://www.omnigroup.com/mailman/listinfo/macosx-admin
