I did not see anything about this issue [i](unless I somehow overlooked it)[/i], hence my post here.
I have noted an apparent compatability issue between Avast free AV v 7.0.1426 and Outpost Firewall Pro v 7.5.2. The File/Folder Locking function in OPFW does not work. In the OPFW Forums, I found a post regarding this problem; it can be seen at this link:
I did not have this compatability issue with the last version of Avast free.
From what is shown in the post, it seems that the conflict is with the aswsnx.sys file in Avast! The only current remedy given is to rename the aforementioned Avast free file although I do not see a file named aswsnx.sys in C:\Program Files\Avast Software\Avast
My question: Is the Avast team going to fix this compatability issue with the next program update?
Well to start with I haven’t updated to OFP 7.5.2, I’m sticking with 7.5.1 for a while yet (I don’t automatically jump on the OFP updates). That said it is hard to believe that there would be a difference in the folder lock feature for these versions, with such a small incremental update.
Though some say this 7.5.2 update is a major update and was a long time in development and a major reason why I didn’t jump on the update when released (I wait several months).
I don’t have any compatibility issue in OFP 7.5.1 and avast 7.0.1426, that said I don’t use the File & Folder Lock feature on OFP as I honestly can’t see the point of it ?
Depending on what folders/files that you lock it could really stuff up things, not just for avast. So a big part of this is what folders you have actually locked ?
So I will enable the file & folder lock feature in 7.5.1 and add a folder that really isn’t crucial to it and see if there is any interaction. But without any idea what you are locking in the OFP file & folder lock I would imagine it difficult to replicate.
A while back I moved any file or folder having personally-identifiable information in them to a USB flash drive from the hard drive. Since Word & Excel do not have a FOLDER-locking option, the file/folder locking option in OPFW was the simplest method I could find to add a little more security to those files/folders. I don’t need to access the H drive all that often anyway.
I’d looked at some of the data-encryption programs as an alternative, such as, Axcrypt, Truecrypt, etc, but felt like they are too complicated for me.
I’ve already submitted some OPFW logs to Agnitum support. They are supposed to get back to me once they’ve completed their review and hopefully, come up with a resolution to this issue. Does this my rationale a little clearer?
I think that the problem you may be getting is the interaction between the autosandbox and MS Word, etc. I have a very old version of MS Office 97 and when I try to run MS Word or MS Excel the autosandbox would suggest running it in the sandbox (no longer the case as I have excluded these files in the autosandbox). Are you getting any autosandbox alerts on Word or Excel when launched ?
But again I can’t understand how that might stop the whole of the file & folder feature from working, but only in areas directly related, as in the interaction mentioned above.
What I can’t understand, even if that were the case is that the avast autosandbox doesn’t work with the file in its original location, but with a copy of it in the $$ hidden sandbox folder, generally in the root of C:\ or other drive letter. So it isn’t messing with the original location even if it were locked.
I haven’t rebooted since I enabled the OFP file & folder lock and a preliminary test was I was able to create a new folder within the supposed locked folder and copy a file from it to the new sub-folder. So I don’t know A) if it would block creations/copy within, using explorer.exe or B) the recently enabled function isn’t actually enabled until after a reboot.
I’ve never received any Sandbox alerts on those files or when first running Word or Excel. In fact, the only times I might receive a Sandbox alert is when running some program…and I don’t recall just what programs have generated an alert in the past.
The file/folder lock “enable” box is ticked in the OPFW user interface, and a password is in place. Normally, if I were to go to My Computer → H drive, OPFW would open the dialog box for me to enter the password to in order to access the drive. It does not do that now, but instead allows me to access the drive as if it were not password-protected.
It’s a mystery…as I mentioned earlier…I had not had this problem before. I just hope Agnitum Support has some remedy for this problem. I really don’t want to have to change AV programs or my OPFW as I think the two have worked well together in the time I’ve had them & they are not system resource hogs like some other security software programs out there.
I haven’t set a password as I don’t want that to remain after I have done my testing and disable file & folder lock. But that shouldn’t stop it working. If it does, for me that is a poor decision to force a user to do something which they don’t want.
If that is the case, then I won’t be able to help further as I flatly refuse to password protect settings. I don’t in avast or any other program and I certainly won’t in OFP, for having once set a password your stuck, you can’t un-ring the bell.
Just wanted to provide an update to the Outpost Firewall Pro [b]file/folder lock compatability issue [/b] with Avast. Below the dashed line is the reply I just received back from Agnitum Support on how to remedy the problem.
Renaming the specified file has re-enabled the file/folder lock option in Outpost Firewall Pro. I can use it with/without a password.
Hi Pete,
It seems that one of the conflict drivers that belongs to third-party software is responsible for this issue. Please, try to rename the file temporarily using the following instruction.
Open “Start - Control Panel - Folder options - View” and untick “Hide extensions for known filetypes”. All extensions will now be visible to you.
Find the following file: aswsnx.sys (usually, it can be found in the following folder: C:\Windows\system32\drivers). If you are using Windows Search, make sure you ticked option to search in hidden and system folder as well.
Rename it to aswsnx.sys.tmp
Reboot your computer in Normal mode, and check, whether this problem would re-occur with modified configuration.
Please, tell us about the results.
We are sorry for the inconvenience.
Personally I would say that the protection/function given by the virtualising/sandbox driver would be the overwhelming choice.
If you are trying to change it back in normal mode then that may be correct, you would have to do it from safe mode.
EDIT: I didn’t ask - why won’t the system let you change it, e.g. what error message ?
You could always try an avast repair and see if that would replace the missing file.
The system generated an "Access Denied...write-protected or disk full" error message. I tried to rename the file in Normal Mode...and that may be why it would not change back (as you mentioned), so I'll go try it again in Safe Mode to see if that works, then post back with the results.
EDIT: I was able to successfully rename the file in Safe Mode.