Exclusions LFN v. 8.3 format?

I'm wondering if there's an official explanation for the way the AMON exclusions work?
Aparently many people can only set exclusions in 8.3 file format {[thread=69207]thread link[/thread]} especially for the 'Documents and Settings' directory while I've tested many LONG file format names and they at least appear to be working great including:-

• C:\PROGRAM FILES\AHEAD\INCD\INCD.EXE
• C:\DOCUMENTS AND SETTINGS\{snipped}\MY DOCUMENTS\WEB_QUOTE.ZIP
• C:\DOCUMENTS AND SETTINGS\{snipped}\MY DOCUMENTS\MY RECEIVED FILES\DOWNLOADS\NEW FOLDER\TEXT DOCUMENT.LOG
• C:\DOCUMENTS AND SETTINGS\{snipped}\LOCAL SETTINGS\TEMP\TEXT DOCUMENT.LOG

Is there some other thing not obvious to me that I'm missing?
Is it perhaps that the format of the exclusion string must match the format of the request made by different applications....ie application request for 'C:\PROGRAM FILES\AHEAD\INCD\INCD.EXE' and C:\PROGRA~1\AHEAD\INCD\INCD.EXE' appear to AMON as two different files that must both be excluded seperately?

 

Hello,

To definately exclude a file from scanning by AMON, it has to be entered twice. Once in todays naming convention, (complete path) and once in the 8.3 naming convention. (complete path)

 

Thanks - made sense to me. Somebody elses agreement helps confirm it.

 

Ha.. funny... it finally works for me too!!!

 

Hello,
does NOD excludes .exe files (in between) when a folder is excluded? Or are they to be specified separately?

THX

 

I'm not sure if I've correctly understood what your asking Hase but if I've got it right then this should be the answer your're looking for.
If you specify a folder for exclusion then all the files only in that folder are supposed to be ignored. All the files in all the subfolders would be ignored as well only if you select that option.

What I'm wondering now that you've mentioned folders is if it would be required to also enter a folder for exclusion with both name formats as well like it is with filenames? (Even if it may not be but I suppose it wouldn't hurt if you did.)

 

You really only need to use SFN (i.e. the MS-DOS 8.3 file naming convention) if the file(s) get invoked that way. Normally, using LFN is sufficient.

You can test this assertion with any file on your system. I'll use BOClean as an example. So, add the full path to your BOClean executable, using LFN only. On my system, this is:

"C:\Program Files\BOClean\BOC412.EXE"

Now, open NOD32 to the AMON window, then go to a command prompt next to the NOD32 window (but not over it) and enter this command:

Code:

type "C:\Program Files\BOClean\BOC412.EXE"

(Or whatever your own path to BOC412.EXE is.)

The TYPE command simply displays the contents of a file--it doesn't run, change, or "do" anything. Some "garbage" will appear in the command prompt window, but you can ignore it--keep your eye on the AMON window instead.

You should not see AMON scanning BOC412.EXE at all. If it does, you entered the exclusion incorrectly. You can hit the up arrow on the keyboard, followed by the Enter key, to keep resubmitting the TYPE command. Nothing should happen in AMON (at least where BOC412.EXE is concerned, and as a consequence of the TYPE command).

Now, in the command prompt window, enter this command:

Code:

type c:\progra~1\boclean\boc412.exe

You will now see AMON scanning BOC412.EXE, because you accessed it by way of SFN.

-------------------

So yes, to "definitely exclude" a file, you do need both SFN and LFN (as ridiculous as this is--and please fix this, Eset). But you really don't need to add entries as SFN unless they're normally accessed that way.

 

As others have alluded to, I think it depends upon the particular process attempting to access the file. If it is programmed to use the LFN then a LFN exclusion in NOD32 should work. If it is programmed to use the SFN then a SFN exclusion should work. The problem is that users should not be expected to know which naming format some 3rd-party app uses. It should all be transparent, users shouldn't have to be concerned with naming formats at all. Unless I'm seriously underestimating the problem for some reason, I don't know why ESET just doesn't always convert every filename reference to one or the other before doing the comparison. As I noted a long time ago in a similar thread here at Wilders, the Win32 API provides filepath conversion functions. It shouldn't be a difficult programming task at all to solve this problem. Maybe ESET does already do the conversion prior to comparison, and people are having exclusion problems for some other reason... but I can't think of any other reason.

 

Exactly--Eset should correct this problem. My point was that you can normally use just LFN and forget about it.

 

Although it may seem simple enough for NOD to figure out the short/long filenames internally, and it is possible but this way is MUCH more effiecient I'd be sure.
You only have to look at it once, set it and thats all and the need for setting exclusions because of repeated scanning should be eliminated with the new 'optimise scanning' feature in 2.13 when it is released

 

More efficient for NOD32, but not more efficient for the user; that's for sure. Please stop with the "my application can do no wrong" stuff.

 

my application?
I'm not sure why but my unconcerned attitude towards a relatively trivial issue seems to trouble you. NOD seems to me to be operating exactly as its been designed to. Of couse it would be better if it were just as efficient, or more so and if as well as that exclusions only need to be entered once. It is my preference also but its not a fault and it is not IMO wrong.
I'm sure ESET appreciate the feedback and all, knowing that people have a preference for it to be different would be something that I would appreciate knowing about if I were the developer but that doesn't mean that ESET are going to build in all the things that everybody wants them to.
My concern is to help people correctly understand how the porgram works and therfore what is required to use it effectively. It doesn't seem right to me to assume that because it is not how you or I (or even if it were a majority of people) would prefer it that it must be wrong - its not.

 

I am not aware of any other programme, a-v or otherwise, that on the one hand provides a file/directory selector using long file names and on the other, may or may not require the use of DOS format names without providing any indication of this. This is bad design, plain and simple, hence my post https://www.wilderssecurity.com/showpost.php?p=268174&postcount=6

 

I think NOD was probably designed around the concept of not ordinarily having exclusions. It is true though, it is quite different having the exclusions setup work like they have done. I too believe that having one entry cover all possibilities of filenames or directories would be better. All a user sees is a relatively minor interface tweak and a significant improvement to the way exclusions operate. Nobody knows except ESET what implementing that would exactly involve despite several peoples understanding of what might be involves and some of the ways that could be done.
My previous post was just trying to get across the point that we as customers are not the head that decides what any software company will do (besides the one we may run each ourselves if we choose) despite our best intentions in making suggestions and pointing out areas for improvement. I really appreciate the good product that ESET have turned out in NOD and am glad to use it within its current form. I trust that their future developments will be generally be pleasing. This trust comes from what little I know of what they're about as a company
Speaking of change in general, any specific change to anything will inevitably be perceived by some to be detrimental even if is completely an improvement or benefit to them. 'People don't always know whats good for them' and 'you can't please all of the people all of the time'
All that aside I've just heard 'on the grapevine' that
"In the soon to be released Beta, the LFN vs. SFN concern no longer exists"
This was not from ESET so while we all wait with baited breath for its release it won't be until then abouts that I will know exactly all the things that may amount to. Anyone else with more specific information I would welcome to hear from on the topic.

 

I think NOD32 is so good, it is worth making better and this is why I make some criticism or suggestion from time to time. I think this is why most people round here do the same.

Sorting out the confusion over excluding files/directories would be very good as at present many people could get the impression that the programme is not working correctly. Currently, they will make the selection from the file/directory selector and discover it makes no difference in many, many cases and unless they subscribe to these forums, they could form a negative impression of the programme; indeed, it may be the difference between them buying a subscription to NOD32 and a competitor.

 

Indeed

 

When you add an exclusion, you expect that file to be excluded. Period. Often times, it's not. This behavior is not documented in NOD32. Maybe they designed it this way, but I doubt it.

Either way, it's not good. At the very least, they should have it so the LFN and SFN paths are automatically added whenever you add an exclusion. But having the user add an exclusion that "isn't really an exclusion" is poor design. <== Note the period.

Or, if I'm wrong, tell me why so many users have been caught--and confused--by this unexpected behavior. That tipsy feeling you have is that of not having a leg to stand on.

 

When you add an exclusion, you expect that file to be excluded. Period. Often times, it's not. This behavior is not documented in NOD32. Maybe they designed it this way, but I doubt it.

Either way, it's not good. At the very least, they should have it so the LFN and SFN paths are automatically added whenever you add an exclusion. But having the user add an exclusion that "isn't really an exclusion" is poor design. <== Note the period.

Or, if I'm wrong, tell me why so many users have been caught--and confused--by this unexpected behavior. That tipsy feeling you have is that of not having a leg to stand on.

This "behavior exactly as designed" has wasted my time, and I don't appreciate that. Defending it defies common sense.

I know it's frustrating to have people like me who refuse to stand up for people and products, come hell or high water, but tough. Deal with it. I've never been a "yes man" or a shill, and never will be.

 

lol
All exclusions work as entered, its just that they are explicitly matched against each applications normally invisible internal requests.
I am sorry to hear that you wasted some time though.
Once more I agree with you that I also think there is room for an improvement in the way exclusions are implemented and your suggestion is pretty much in line with my thinking as to what may be the simplest way to go about it.