The above trick works well for either a single install, OR to "share" the COMODO directory & database between multiple Puppies, because after loading the SFS in each one, I merely delete the 'loaded' COMODO directory from /opt & sym-link the external one back in its place. I'm guessing you've simply run out of space, because I doubt you expected the database to be quite so humungously large! Having done this, and updated those URLs/updated the database, there's then usually enough room for that monster database file. I then delete the original, and sym-link it back into position. The way I get round it is this:- After loading the SFS, before doing anything else I copy the /opt/COMODO directory out to somewhere where I have plenty of space. In this case, because the normal SFS unload process has been interrupted, those entries don't get removed from /root/.jwmrc either.ĭuring the course of the original thread on the Murga Forum, we were more concerned with getting the thing to actually run than we were in worrying about whether it would unload properly afterwards.
You also find that, although the entries in /usr/share/applications have in fact been deleted/removed, they still show in the Menu. Consequently, this jams the unload process up and you end up having to manually delete /opt/COMODO.
Because of this, when you try to unload the SFS, it says it can't ("Files in use"), etc, because that 564 MB database file ( bases.cav) is not part of the original SFS file. The only snag with using Comodo is that it saves its signature database file inside the /opt/COMODO /scanners directory. Let's see if I can shed some light on what's happening here.
0 kommentar(er)
