We would very much appreciate it if you would submit your bug report in the format requested here. For the reasons why see below.
Many thanks in anticipation
WHY YOU SHOULD FOLLOW THESE GUIDELINES
Bugs/issues can be impossible or very time consuming to fix if not well described. Since CIS is free, development time is limited. So if you want your issue fixed, please use the format below to describe it.
To avoid clutter, issues not described in the format below your post will not be moved to the ‘moderator verified’ issues topic. This means that the developers may not look at it.
What you did: Update Comodo to Name=“COMODO - Firewall Security” Version=“50422421” ProductVersion=“5.0.162636.1135”. Reboot twice.
What actually happened or you actually saw: Application not recognized even if registred as “Trusted Application” in the registry (picture happened). Path and Filename inconsistant. Detected as semi 8.3 : “C:\PROGRA~2\Squeezebox\server\SqueezeSvr.exe”. SqueezeSvr.exe is a local server for music and internet radio.
What you expected to happen or see: No alert
How you tried to fix it & what happened: Recreate a policy from scratch. Changed the path to “C:\Program Files (x86)\Squeezebox\server\SqueezeSvr.exe” in the registry . Stop and restarted the service which is the source of the problem.
Thanks for a very interesting bug, carefully described.
Just to check:
The problem is that you cannot make this file trusted by the firewall, or create any other allow rule for it. Because of this you keep getting alerts
You suspect that the cause is the way that CFW is storing the programs path and file name in the registry
The problem appears to be that it is stored in a mixture of 8.3 and widows path formats
The last issue needs further clarification. Are you suggesting:
a) that the combination of inverted commas “” and contracted directory name Progra~2 is the source of the problem. Please say if the directory entry has these inverted commas “”
b) the combination of the contracted directory name and uncontracted file name (& indeed other directory names) is the source of the problem?
Yes. That the seems to be the issue. Comodo can’t stop bugging me with the alert window about “SqueezeSvr.exe” which is declared as a trusted application. Even if I check again the alert window as a “trusted application”, I got a new alert window asking what to do with “SqueezeSvr.exe”
No I added “” in the published post. See the appended picture which show how the application is declared.
That seems to be. And that happens only to the very special Program Files (x86) folder name, not to others. I think MS done a very special mixture for this folder name to separate 32bits application and 64bits ones. Squeezebox.exe is stored in the folder C:\Program Files (x86)\Squeezebox\server. The program path should be:
C:\Program Files (x86)\Squeezebox\server\Squeezebox.exe (windows)
C:\PROGRA~2\SQUEEZ~1\server\SQUEEZ~3.EXE (8.3 name in process explorer v11.33)
Just downloaded the latest build of CIS to see whether I could return to COMODO. No way, this very basic bug is still around! Unreal. I reported this in March 2010 on X(32) - you ignored and “orphaned” my report. roncomod then reports the same problem again in September 2010 on Win7 and here we are in May 2011 and this is still not fixed. This great product of yours remains inaccessible to me so long as you do not sort out the problem with your filename expander. This cannot surely be beyond the ken of men to fix?
This problem is not related to SqueezeServer per se. It can happen with any process. There was no way that I, for example, could get MS Outlook to work. The key is to look at the CIS process list (make sure to enable full path display). You will get problems with ANY process that uses 8.3 mangled path components yet reports its basename as a LFN (eg C:\PROGR~2\Squeezebox\server\Bin\MSWin32-x86-multi-thread\socketwrapper.exe). I have posted on a numerous forums on M$ but regret that I never got to the bottom of how or why certain processes would use 8.3 names. Mind, this genuinely seems to be a CIS problem. M$'s standard APIs hide application developers from this OS non-sense. CIS must have gone one level below and mucked up the decoding. Chances are that it looks at the basename, sees a non-mangled LFN and decides that the file path won’t be 8.3 either. Except that it is. And hence does not match the rules. Or so I am speculating. What do I know? Regrettably it means that CIS is totally useless on my installation. (Since not all people report this problem, it is quite clear that my installation has something to do with provoking this problem too. What this might be, I will never know.)
Unfortunately, I’m not seeing any file name corruption or short file names in the CIS Process viewer, regardless of the path length or complexity, so I haven’t been able to do much with this. Is there anything else you can tell me? One obvious question, have you tried disabling short file name creation in the registry?
I am not surprised that you cannot find such a problem on your m/c, Radaghast. It seems that it is some kind of unfortunate constellation that brings it about. Unfortunately, I never found a way of getting rid of it. It’s been a long while but, yes, there was some way or other to tell the OS not to create 8.3 names. When I tried this with Outlook, the result was a total fiasco. All I did was to disable 8.3 names, copy OUTLOOK.EXE to BOO.EXE, remove OUTLOOK.EXE and rename BOO.EXE to OUTLOOK.EXE. After that, all hell broke loose. The MS Office rubbish is some sort of cunning collaboration between file system and registry. I concluded that there was no way that I could fix this problem w/o completely re-installing the whole m/c - an option that really did not appeal.
I do not know how COMODO relates to this board. I would hazard a guess that somewhere low down in the CIS source code, there is a basic mapping function whose role it is to unmangle 8.3 file names. It is probably very short. If someone just took a glance at it, using the description of the problem we have given here so far, chances are they would spot a stray IF (taking some shortcut) in an instant and the problem could be fixed.