In the local safe files list (ie w/o cloud support, and CIS is made so it can operate w/o cloud support) CIS cannot tell between a situation where you have:
two safe versions of a safe file
one safe version one malware version
one true version one counterfeit version
one version firefox which is a browser and one which is a game called firefox
Cos anything can call itself say Firefox.
So it cannot just use only the most recent version
So I think the question should be 'why does CIS not append version numbers and/or version a), b) c) to separately identify the versions with separate hashes (which might be different apps)?
Sure, I understood this. But, just as L.A.R asked… this being the case why would a non-existent file (ie. a previous version of an application with a different hash) be considered valid and there be no need to remove them? And more specifically, why doesn’t purge work in this instance? And… how do you know which is which?
Because you cannot know its a previous version of the same app - app names are not controlled and policed.
You could have an option to de-dupe do this, a different sort of purge - ‘remove apparent duplicates with different hashes leaving just the most recent according to the file modification date’.
You should in my view disambiguate them, probably as Firefox a), b) c) AND add in the version string to the name.
You could I guess use certificate info for this, but the TFL is supposed to be able to operate separately from the TVL. And if its vendor trusted it would not normally be on the TFL anyway.
Fine by me, but you do realise it’s currently locked? Which, as a Mod, is also fine by me. But, a Beta Tester (L.A.R. Grizzly) brought this up… I was merely trying to help make sense of the answer he got.
Now…
If you cannot currently differentiate the entries how would the above be possible? Does the hash now show on the entries in 5.8?
Also note that some people keep mutlip versions of the same app on their computer.
I have two k-meleons - one which is faster, one which is later and more compatible.
Sure, but those entries really would be valid as the files actually exist (although probably not in same folder I assume). But, how is a non-existent file valid?
Why can’t the purge button just remove the duplicates and keep the existing one? It can tell it’s not longer there as the hash will not match. In the rare event an old version of a program is added back it can always be added again. This seems so simple and logical to me.
Fine by me, but you do realise it's currently locked? Which, as a Mod, is also fine by me. :)
Having a bad finger day, sorry... Just mashed and repaired your post too :(
If you cannot currently differentiate the entries how would the above be possible? Does the hash now show on the entries in 5.8?
I think they should be dis-ambiguated. But the judgement that they were diff versions of the same app would always be a guess (posh name: a heuristic). That's one reason for making it optional. The other is that some people want to keep multiple trusted version of the same app on their computers.
Sure, but those entries really would be valid as the files actually exist (although probably not in same folder I assume). But, how is a non-existent file valid? :)
It's not of course instantaneously valid, but should only be removed if purged IMHO - think/hope Egemen is going to sort the problem of pruging not working. Purging could be automated. But then if people are taking files on and off their computer.... There is a reasonable reason not to purge, so I'd prefer it optional.
Well purging and de-duping are different operations, people may want to do them separately. Also the de-dupe would be basically educated guess work, but useful educated guesswork, I agree. It could offer and ask the user to confirm the deletion list.
Files are actually being policed. Executables, .exe files, are protected files. If a file gets overwritten by a rogue version then that is user error. Either for allowing rogue installer unlimited rights or doing it him or herself using Explorer for example.
I don’t think I would ever not want a duplicate removing and I should think that would be true for the majority of users. An exception could be programs on removable drives (I never do that) that are not always there but that would apply to purging as well as removing duplicates.
Duplicates should remain if two versions of the software are installed.
Ah you slightly misunderstand me here. What I said were app names are not policed - ie what a vendor chooses to call an app. That’s what CIS picks up in the TFL, I think.
So two vendors could call an app firefox. Obviously there could be trademark issues with well known apps like this. But I think utilities and smaller scale apps sometimes share the same name. It’s not necessarily a rogue if its called the same thing.
For the user to get round this you’d need to offer the option of renaming TFL entries at the point of adding them.
The purge could keep missing files if they are on a removable drive. This is a different issue to removing multiple versions as it applies even if there is just one version.
Wouldn’t the two different versions of the same app have different hashes? If that’s the case, having both of them on the list would be acceptable. I was just concerned about previous versions that no longer exist being left on the list. Couldn’t hash comparison be used to clear up this anomaly? Maybe I’m just not understanding the procedure.
–Edit–
I just looked at my TFL and now I notice multiple entries of cfp.exe, cfpupdat.exe and cmdagent.exe. CIS is reproducing itself! >:-D
As soon as he USB is removed they no longer exist in one sense - but in multiple versions apps on USB keys we are talking of unusual issues - not sure CIS needs to bother - just get the basics right. (They could exist as network files too). Its surprisingly difficult stuff but I think we have thrashed the main issues and made some good suggestions.
But, a Beta Tester (L.A.R. Grizzly) brought this up… I was merely trying to help make sense of the answer he got.