A couple of months ago, my problem with being unable to upgrade Xfprot signatures resolved itself as mysteriously as it began, and xfprot became useable again.

Then I discovered, the hard way, that the configuration settings would not save, despite a cheery pop-up that announces "settings saved" or words to that effect.

I experienced a disastrous loss of all the applications and customizations in my Puppy Linux 4.12 Retro system, when I accidentally told xfprot to list every file scanned, and set it to scan the entire hard drive. Instead of copying the log to one of my spacious hard drives, as indicated in the "saved" log path, it copied to my limited .2fs file, filling it until it could no longer function.

Later experimentation proved that, the successful save message notwithstanding, xfprot always reverts to the default setting for both scan path and log path when opened, requiring tedious re-entry of these paths every time the utility is used.

Furthermore, before beginning the scan, the program asks, "overwrite existing log file?", and aborts if the answer is no. While this is a rather stupid waste of time, requiring one to rename the previous log if one wants to preserve it, I suppose it could be considered as a sort of warning system for the mishap I described above. If you don't get the warning, you may be about to write the log to the default location in /root/.

I'd hoped that the latest version of Pupply Linux (4.2 final Retro) might have fixed these two problems with Xfprot, but when I booted it cleanly from a freshly burned CD, Xfprot behaved exactly the same as before.

I'd be interested in knowing whether this is a flaw in Xfprot, or only in its implementation in Puppy Linux. A fix would be even better, of course. Is there no other member of this forum using xfprot, or at least, willing to run it for a few minutes to check for these two problems?