Exlusion Wildcard --- Invalid Path?

[dunc 0]

Hi all,

using Nod31 11.1.54.0 on Win 10 here... it seems the way how I can add exclusion entries for folders and all its subfolders/contents is not working anymore how it used to in older versions, or how it is indeed still stated in the help texts. So I need a quick hint here on how to do it properly now.

The help states:

1) "to exclude all files in a folder, use *.*" - e.g. "D:\foobar\*.*" this would then include all files in the folder "foobar", but NOT in any subfolders.

2) "to exclude including all files and subfolders, use *" - e.g. "D:\foobar\*" this would then include all files in the folder "foobar" AND in any subfolders.

And this his how I setup my exclusions in the past, and I have some of these "type 2" wildcard entries still in my list.

However: if I want to add some new exclusions for "a folder and all its subfolders", it seems the UI does not allow me to add the single "*" to a path anymore. If I select a path from the exclusion UI, it is displayed without a trailing backslash, e.g. "D:\foobar". Adding a trailing backslash and "*.*" works fine, e.g. "D:\foobar\*.*" (see attached image eset_wildcard_01.png).

But when I try to add the backslash and only a single "*", e.g. "D:\foobar\*", the UI now marks the text in red and with an error icon, stating "invalid path" (see attached image eset_wildcard_02.png).

So my questions are: is this a bug or am I missing something? And if the latter, what is the correct way now to exclude a folder and ALL its contents/subfolders from real-time scanning in Nod32 11.x?

Thanks a lot!

[Marcos 5,070]

Wildcards work only at the end of paths in file names unless the threat name is specified. Try excluding only the path d:\foobar. Also please explain why you want to exclude a specific folder or file; is it because a PUA is detected there and you want to use it anyways?

[itman 1,659]

Try "D:\foobar\\" less the quotes if "D:\foobar" does work. I know the "\\" notation works for HIPS rules.

Edited June 28, 2018 by itman

[dunc 0]

6 hours ago, Marcos said:

Wildcards work only at the end of paths in file names unless the threat name is specified. Try excluding only the path d:\foobar. Also please explain why you want to exclude a specific folder or file; is it because a PUA is detected there and you want to use it anyways?

Marcos,

thanks for your reply.

When you say "try excluding...", does this translate to "this is the way to properly do it"? Or does it translate to "not sure myself, please try and check whether it works"?

Keep in mind, I am only trying to make sense of the official documentation available here:
https://help.eset.com/eav/11.1/en-US/idh_config_exclude.html

There is no mentioning of any restriction regarding "only work with filenames", or "need to specify a threat name". So now you got me properly confused.

As for the "why", these are folders that hold some git development repositories, and I can not allow *any* potential data cleanup or removal in there.

 

2 hours ago, itman said:

Try "D:\foobar\\" less the quotes if "D:\foobar" does work. I know the "\\" notation works for HIPS rules.

itman,

thanks for your reply as well.

Using double backslashes plus the wildcard also is marked as "invalid path" in the ESET UI, unfortunately.

[Marcos 5,070]

I've tested it and both c:\%folder%\* and c:\%folder%\*.* exclude everything in %folder% and its subfolders.

[itman 1,659]

According to the Eset help documentation:

Quote

• If you wish to exclude all files in a folder, type the path to the folder and use the mask “*.*”.
• To exclude an entire drive including all files and subfolders, use the mask "D:\*".

 

I interpret the above to mean:

 

1. *.* applies to files only in the specified folder..

2. * applies to all files and subfolders in the specified folder.

 

    

Edited June 28, 2018 by itman

[dunc 0]

59 minutes ago, Marcos said:

I've tested it and both c:\%folder%\* and c:\%folder%\*.* exclude everything in %folder% and its subfolders.

Hrm... how can you even enter a path with a single * at the end? Here, this always leads to the "invalid path" error message I described in my 1st post and confirmed with the screenshot.

Can you think of a reason that you can enter a path with a single * at the end, while I can not?

At least here on my machines, this behavior is new for 11.x, it definitely worked properly with 10.x. I got to admit that I am not sure whether it started for 11.x right away (e.g. 11.0.x), or whether it started later during the 11.x run (e.g. 11.1.x)

Furthermore...

47 minutes ago, itman said:

I interpret the above to mean:

 

1. *.* applies to files only in the specified folder..

2. * applies to all files and subfolders in the specified folder.

...I agree with this interpretation, and this is indeed how it worked in the past with older versions of Nod32.

So overall I *assume*:

a) the docu is still correct and describes how it is supposed to work

b) your test of * vs. *.* behaving identical leads to the conclusion that there is some global issue - either with the docu being wrong, or the program behaving wrong

c) whatever is causing the issue on my end NOT being able to enter a single * at all might indeed be isolated to my specific systems, for some reason

For A and B, can we have a binding statement from ESET? Not trying to be a PITA or similar, I just want to make sure that there is no further "self-inflicted confusion" in that matter.

For C, is there any way to further analyze this on my system?

Thanks!

Edited June 28, 2018 by dunc
automatic cencorship?

[itman 1,659]

I just tested in Internet Security 11.1.54 and the issue manifested there:

When you select a path via the search option; i.e. ….., the above path shown is C:\DonsScripts.

Appears to me its a bug or Eset needs to update its help documentation.

[Marcos 5,070]

Will be fixed in the Configuration Engine module 1685.8 so entering e.g. c:\folder\* will be possible. Currently you can use c:\folder\*.* instead which has the same effect.

[dunc 0]

2 hours ago, Marcos said:

Will be fixed in the Configuration Engine module 1685.8 so entering e.g. c:\folder\* will be possible. Currently you can use c:\folder\*.* instead which has the same effect.

Thanks a lot!

So *two* bugs to be fixed:

1) Make it possible again to enter "<folder>\*", which leads to exclusion of the folder contents and all subfolders

2) Adjust entering "<folder>\*.*", so that it leads to exclusion of only the folder contents, but NOT the subfolders

Correct?

[Marcos 5,070]

1, This will be fixed.
2, This cannot be fixed / changed.

Exclusions like "...\*" are equal to "...\*.*".

[dunc 0]

So, regardless of the exclusion format, there is no possible way to exclude ONLY the files in a specific folder "main level", but NOT the ones in the subfolders using wildcards?

Not complaining, but if that is the case, I humbly suggest adding that info to the documentation (see links above), since the statements there allow for another interpretation.

Stupid question: what happens if I only exclude the folder, without any wildcard at the end?

Edited June 29, 2018 by dunc

[itman 1,659]

Looking though the previous replies, it is unclear if you ever tried the current path default setting of C:\somefoldername? Does that only exclude files in the directory but not any sub-folders contained within?

Also in most Eset GUI sections where a file/folders exclusion capability exists, "*" is equivalent to "*.*".

Edited June 29, 2018 by itman

[dunc 0]

I don't have a proper testing environment where I could try defined use cases with defined results. Even if I would try comparing "<foobar>" vs. "<foobar>\" vs. "<foobar>\*" vs. "<foobar>\*.*", I would not know how to make a statement about the results, since I do not have any testing files available that could help me.

But in the end, all I want/need is the product docu and the product behavior to be "in sync", so that I can look up the answers to these questions without a doubt whenever I'm unsure.