Jump to content

Not functional ignoring of NTFS Symlinked folders


Poutnik

Recommended Posts

Retyping the scenario

I have in My Vista64 Home Premium SP2 folder c:\users\User\Downloads redirected by NTFS folder symbolic link to E:\Downloads.

During scanning of disk C: MBAM scans c:\users\User\Downloads i.e. E:\downloads what I do not want.

When I try to add c:\users\User\Downloads to exclude list, it adds instead of the symlinkd the real target folder E:\Downloads.

It would not matter, if MBAM respected this.

But if I trigger next scan, it is scanning all the c:\users\User\Downloads = E:\Downloads again.

For NTFS Junctions it works correctly as expected.

Link to post
Share on other sites

Greeting to all MBAM developers...

Well, it may be more clear from my original post than fro this new thread.

If I add symbolic link c:\users\User\Downloads, it adds E:\Downloads to exception list.

And keeps later scanning c:\users\User\Downloads

I am aware about standard ways of user folder redirections, but I think the Windows did not offer redirecting of this folder, so it is probably the historical reason why I used in deep past this solution.

In fact I am more interesting in fixing way how MBAM works with standard NTFS features, than in workaround.

I use lot of redirecting for general folders, but usually using Junctions. I can as well logged as admin replace SymlinkD by Junction.

Link to post
Share on other sites

Better said, I might forget about that Windows feature, creating symlink, as it is possible for the folder.

But it does not change anything on MBAM should be able to add symlink to exception, as the above is applicable to profile folders only.

Link to post
Share on other sites

I see. I did a bit of research (via Wikipedia) on the subject and it appears that this is actually expected behavior and is a limitation of symbolic links themselves, not a bug in Malwarebytes Anti-Malware. From here:

Symbolic links are automatically resolved by the file system. Any software program, upon accessing a symbolic link, will see the target instead, whether the program is aware of symbolic links or not.
This means that, because they are resolved by the file system itself, there's no possible way for Malwarebytes Anti-Malware not to be redirected to the linked location.
Link to post
Share on other sites

No, it does not, it scans c:\users\user\downloads.

What I do not understand why MBAM acts differenctly at exception addition and at scanning.

Should not it see either c:\users\user\downloads. either e:\downloads in both cases ?

Cannot be the issue during eception addtition the target is provided to MBAM by Window pick up dialog,

while during scan the original symlink is used directly by MBAM ?

Link to post
Share on other sites

It brings another question :

Let suppose folder A is scanned by the scan

Let suppose folder J is junction to A

Let suppose folder S is folder symlink to A

Both J and S are in otherwise scanned folders

Is scanned just A, or J a/o S as well ?

Link to post
Share on other sites

No, it does not, it scans c:\users\user\downloads.

What I do not understand why MBAM acts differenctly at exception addition and at scanning.

Should not it see either c:\users\user\downloads. either e:\downloads in both cases ?

Cannot be the issue during eception addtition the target is provided to MBAM by Window pick up dialog,

while during scan the original symlink is used directly by MBAM ?

MBAM uses Windows Explorer for the add to ignore list dialog. I'm guessing that would be why since Windows Explorer does not redirect and reports it as being C:\Users\User\Downloads. MBAM itself (the scanner) when reading the location from the NTFS disk reads that location as being E:\Downloads because that is what the system tells it that it is.
Link to post
Share on other sites

MBAM uses Windows Explorer for the add to ignore list dialog. I'm guessing that would be why since Windows Explorer does not redirect and reports it as being C:\Users\User\Downloads. MBAM itself (the scanner) when reading the location from the NTFS disk reads that location as being E:\Downloads because that is what the system tells it that it is.

Hmm, is not it exactly the opposite ?

If Explorer reports it as C:\Users\User\Downloads, would not MBAM add C:\Users\User\Downloads to the list ?

And, when scanner reads the location as E:\downloads, should not check it against the exception list ?

Link to post
Share on other sites

Hmm, is not it exactly the opposite ?

If Explorer reports it as C:\Users\User\Downloads, would not MBAM add C:\Users\User\Downloads to the list ?

And, when scanner reads the location as E:\downloads, should not check it against the exception list ?

What you see in Explorer and what the system reports to MBAM are two entirely different things, hence the reason that it's excluding E:\Downloads.

The point is, MBAM is doing what it's supposed to do. You set up a symlink, and according to how symlinks are supposed to function, if you point any program at the original location, it gets redirected to the new location instead, so if you're trying to exclude C:\Users\User\Downloads from MBAM, it won't be possible as long as there is a symbolic link pointing to E:\Downloads.

Link to post
Share on other sites

What you see in Explorer and what the system reports to MBAM are two entirely different things, hence the reason that it's excluding E:\Downloads.

The point is, MBAM is doing what it's supposed to do. You set up a symlink, and according to how symlinks are supposed to function, if you point any program at the original location, it gets redirected to the new location instead, so if you're trying to exclude C:\Users\User\Downloads from MBAM, it won't be possible as long as there is a symbolic link pointing to E:\Downloads.

That still does not explain why MBAM in one case see E and in other case C....

What if there was manual option to exclude folders ?

Link to post
Share on other sites

What you see in Explorer and what the system reports to MBAM are two entirely different things, hence the reason that it's excluding E:\Downloads.

The point is, MBAM is doing what it's supposed to do. You set up a symlink, and according to how symlinks are supposed to function, if you point any program at the original location, it gets redirected to the new location instead, so if you're trying to exclude C:\Users\User\Downloads from MBAM, it won't be possible as long as there is a symbolic link pointing to E:\Downloads.

What if we are able to put manually to the exclude list c:\users\user\downloads ?

It would be useful even for normal folder cases. Many KBD oriented people do not like Explorer way of picking folders.

Link to post
Share on other sites

That still does not explain why MBAM in one case see E and in other case C....

What if there was manual option to exclude folders ?

It's not MBAM that sees it as C:, as I explained, it's Explorer (which is what we use for our browse dialogs in MBAM, including the one used for adding items and locations to the Ignore List).
Link to post
Share on other sites

What if we are able to put manually to the exclude list c:\users\user\downloads ?

It would be useful even for normal folder cases. Many KBD oriented people do not like Explorer way of picking folders.

You actually can using the Business version of Malwarebytes Anti-Malware, however that still would not resolve the issue. You have applied a symbolic link to that location, so any program (MBAM included) will be automatically redirected to E: no matter how it is entered. That's the entire point of a symbolic link.
Link to post
Share on other sites

What if we are able to put manually to the exclude list c:\users\user\downloads ?

It would be useful even for normal folder cases. Many KBD oriented people do not like Explorer way of picking folders.

E.g. One would like to paste copied folder pathname, but clipboard content is useless, if he has to pick it up by Explorer.

Even editing of the full exclusion list as a text would be useful.

Link to post
Share on other sites

E.g. One would like to paste copied folder pathname, but clipboard content is useless, if he has to pick it up by Explorer.

Even editing of the full exclusion list as a text would be useful.

Just as I said before, it still would not matter. Any APIs used to determine the location of the excluded folder would result in the system reporting it as E: instead of C: because of the symbolic link. As I said, that is the purpose of a symbolic link so what you're asking for is for MBAM to somehow do something that violates the entire purpose of a symbolic link. If that were even possible, then a symbolic link would not be functioning as it is supposed to.
Link to post
Share on other sites

It's not MBAM that sees it as C:, as I explained, it's Explorer (which is what we use for our browse dialogs in MBAM, including the one used for adding items and locations to the Ignore List).

If MBAM does not see it as C, why it is scanning c:\users\user\downloads and why does not ignore E:\downloads ?

Is E:\downloads that MBAM gets from explorer to exclude different to E:\downloads that MBAM is said to see if scanning ?

You know, I need not to solve it for myself, but at least in business version it should be addressed.

Link to post
Share on other sites

If MBAM does not see it as C, why it is scanning c:\users\user\downloads and why does not ignore E:\downloads ?

Is E:\downloads that MBAM gets from explorer to exclude different to E:\downloads that MBAM is said to see if scanning ?

You know, I need not to solve it for myself, but at least in business version it should be addressed.

Perhaps it is scanning E: and the GUI of the scanner just shows it as C: (but the file system redirects it to E: while scanning). I can't say for certain if that is the case or not, but that would be my guess.
Link to post
Share on other sites

Just as I said before, it still would not matter. Any APIs used to determine the location of the excluded folder would result in the system reporting it as E: instead of C: because of the symbolic link. As I said, that is the purpose of a symbolic link so what you're asking for is for MBAM to somehow do something that violates the entire purpose of a symbolic link. If that were even possible, then a symbolic link would not be functioning as it is supposed to.

E.g. latest version of catalogue software Cathy does not follow scanning junctions nor symlinks, as previous versions did,

as well as NTFS Autocompress utility offers option if it should follow junctions/symlinks.

Link to post
Share on other sites

E.g. latest version of catalogue software Cathy does not follow scanning junctions nor symlinks, as previous versions did,

as well as NTFS Autocompress utility offers option if it should follow junctions/symlinks.

And, Cathy is very fast.

MBAM can test folder, if it is symlink, and if it is, if target is in exclusion list.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.