@keniv :-
Hoo, boy. Let's see if I can shed some light on what's happening here..... 
The only snag with using Comodo is that it saves its signature database file inside the /opt/COMODO/scanners directory. 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. Consequently, this jams the unload process up and you end up having to manually delete /opt/COMODO.
You also find that, although the entries in /usr/share/applications have in fact been deleted/removed, they still show in the Menu. In this case, because the normal SFS unload process has been interrupted, those entries don't get removed from /root/.jwmrc either.
During 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.
---------------------------------
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. I then delete the original, and sym-link it back into position. Having done this, and updated those URLs/updated the database, there's then usually enough room for that monster database file. I'm guessing you've simply run out of space, because I doubt you expected the database to be quite so humungously large!
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. Upon unloading the SFS, all proceeds as normal; all you get left with is a "dead" sym-link in /opt, which can be removed as & when you get around to it (because it doesn't interfere with anything).
--------------------------------
I've been experimenting this afternoon with building a 'portable' standalone version which you could then run from a USB stick. However, this turned out to be a flat 'bust'; it appears each individual install is intimately tied to the host ID of the OS into which you've installed it. I built a portable version, and initially it all appeared to work well.....but upon booting into another Puppy, despite firing-up and starting OK, it had lost its settings, 'lost' the update URLs, and had even forgotten it had ever been updated! That 500+ MB 'bases.cav' file was sitting in its normal location inside the 'scanners' directory, but the application insisted - even looking straight at it! - that there was nothing there.....
COMODO AV 4 Linux doesn't produce any config files, apart from a nightmarishly complex .xml file inside the /COMODO/etc directory.....a good part of which is in hex code memory address register locations.
I said "Sod it", and gave up at that point..! 
------------------------------------
Anyway, to recap; the simplest way to avoid that 'jammed-up' SFS unload process is, quite simply, to move the /opt/COMODO directory somewhere outside the 'save' and sym-link it back into position, before you do ANYTHING else. I appreciate it's a load of tiffling about, but it does mean the thing CAN be unloaded again without any hassle. This is how I've been doing it for a long time, and it's been perfectly happy to run like that.
If you want shot of it completely, just remember to delete the external COMODO directory as well. Sorted.
Top & bottom, to my way of thinking it boils down to one thing.....and that is, the developers didn't think the thing out very well when they coded it originally. Anyone with a shred of sense would have written it to locate that huge signature database file somewhere else completely, given how big it gets.
(*shrug*)
Mike. 
)
That was the one thing I always used to disable during the years when I, too, used C.I.S full-time in XP. If you didn't, you couldn't get owt done for the constant interruptions with on-screen popups!