Could some1 of you eggheads explain to me why CIS blocks every other JD autoupdate and allows JD update itself on every other?
File which JD blocks is jdownloader.jar and only prioblem is that it appears on Contained only not on filelist so can’t whitelist it (and adding it to Trusted on Contained doesn’t allow it to run)…
Apparently that .jar file appears on admin side of CIS not on regular user side even when updating is started on reg. side and no elevation asked.
I have added all JD related I can see as regular user but that jdownloader.jar doesn’t appear on reg. user side of file list only in containment (as blocked) and saying that it’s trustable file there doesn’t help.
I give up on trying to figure how to make JD autoupdater to work with CIS since .exe is Trusted but still gets Fully Virtualized when update is attempted to install.
Well new CIS and old problems, on prev. version of CIS it finally decided to allow JD’s autoupdater but on new it blocks jar file (saw it on Containeds but not on File list so couldn’t add it to Trusted).
I tried the June 14th build of JDownloader 2 against the new Comodo (build 8040).
First off, JDownloader drops itself into Users/Local and has 2 ways to start it: JDownloader2.exe and JDownloader.jar
The exe is Trusted and will start and will update without issue. However if you initiate the JDownload.jar file (assuming you have Java installed) Comodo WILL contain that file AND give a Firewall alert when a connection out is found.
The reason for the difference is that although the exe file is Signed, the jar file is not, so Comodo is acting the way it is supposed to (Trust no unsigned file).
The easiest way to resolve your issue is to create a shortcut to the JDownloader2.exe file and run it that way. Otherwise if running the JDownloader.jar file directly Choose the Do Not Contain again popup and at the FW alert click Allow and Remember.
Hope this helped.
m