ABE was working in our test environment back in September when we made the code change & put out the beta for you to test, and was also working for at least one other person who provided feedback outside of the forum at that time. We no longer have ABE set up in a test environment to check it still works, but there's no reason it shouldn't.
What happens if you run this test app against the server and share in question?
ABE_Check.zip (1.72 MB)
Leo,
Thanks for the reply. Sorry that let so much time elapse before commenting back that ABE didn't seem to be working correctly.
I have run your ABE_Check.exe application on my own PC and the Terminal Server where my users run Opus. I got the same results in both locations. Below is a screen capture. It shows that ABE is enabled on the share.
To re-iterate the problem: when user B makes a change to a folder that user A can't see because of ABE Opus suddenly displays the previously invisible folder to user A. The folder goes away if the user refreshes or tries to access it. A quick check of whether Opus is hiding folders that ABE should prevent them from seeing isn't enough. You have to trigger some file activity in one or more of the hidden folders. I can only guess the other person who checked this didn't watch what happens when file activity is triggered in the hidden folders. This is what I observed before the change was made to add support for ABE to Opus. I haven't observed any change in the behavior of Opus regarding ABE enabled shares.
I'm currently running Opus 11.10 (x64 on the Terminal Server and x86 on my workstation)
The file server hosting the share is Windows Server 2008 R2 SP1
The Terminal Server where I have observed this behavior is Windows Server 2008 R2 Enterprise SP1
Today, I will confirm that the problem happens with Opus 11.10 on Windows 7, too; so we can be sure that it's not something about Win2k8R2EE SP1 that's behind this. I will post an update shortly.
No, we definitely checked that. Blocking change notifications from making inaccessible folders appear when ABE was in use was the one and only point of the code change.
Since ABE is being detected, and quickly (and assuming you tested using the same machine + user account as is seeing the problem; is that correct?), it could be that the test for accessibility is wrongly seeing the folders as accessible. Or it could be that the change notifications aren't what we expect them to be.
Is there a difference if you use a mapped drive letter vs a UNC path in Opus?
Leo,
I did check from a computer (our Terminal Server) where I have observed the problem but I didn't use the same user account with which I have observed the problem. I also don't know if UNC or mapped drive has an impact (we only use mapped drives). I'll check into both of those things shortly and post an update.
Jason
ok, I have some updates...
I have run the ABE_Check.exe app from within a user account on my Terminal Server from which the problem has been observed (as recent as a few minutes ago). I get the same results. It shows that ABE is enabled on the share and it returns that information just as quickly as in the image in my earlier post.
I can confirm that using a UNC path instead of a mapped drive DOES have an impact on this problem. If I use a UNC path I don't observe the problem. I only observe the problem when using mapped drives. Unfortunately, that's what we use for all our network shares and I'm not really in a position to change that. The general concept and even the specific drive letters are embedded in our procedures and culture.
I can also confirm that the problem occurs (as described in the preceding paragraph) when using Opus on Windows 7 not just Windows Server 2008 R2 EE SP1. That, I'm sure, is a helpful detail.
Here's a bit more information that might be helpful. When I create a new folder somewhere inside a folder that user can't see Opus automatically shows them the folder in their File Window but when I delete that new folder Opus doesn't automatically remove the folder from their File Window. Put another way, Opus reacts to the creation of the new folder but not the deletion of that same folder. If there are other file/folder operations you want me to test, I can do that.
Based on what I have observed now, I would guess that you're right; when the share is being accessed via a mapped drive at least some of the notifications are somehow different from what you're expecting.
Jason
Looks like the change we made only affected UNC paths, not mapped drive letters.
Currently we have 11.11 scheduled for release next week so I don't think a fix will make it into that, but we should be able to fix this for the next beta.
If you could give us feedback in less than three months next time it would help 
Yes, sorry for the delay last time. I knew it wasn't working but kept forgetting to update this topic. I know it's not very helpful to wait so long to provide feedback. I develop SAS code for internal use and I know I'd be frustrated if I had that happen to me. 
I look forward to an upcoming release that includes ABE working for mapped drives as well as UNC paths.
As ever, Opus is awesome (literally every computer user should use it) and I really appreciate the effort that you guys put into the product. Our entire office uses it every day all day and has for years.
I guess it's pure coincidence. Yesterday a collegue of mine sent me a screenshot, where the treeview of a mapped drive did show only 1 subfolder, while the filedisplay showed all available folders.
I don't use mapped drives myself and didn't ever noticed that, so I tried to reproduce on my own computer with the same network path mapped. All the folders were visible in the treeview for me, but DO got unusable. It would not respond for huge amounts of time (2-3 minutes), then a click anywhere would be ok, then stalling again for "ages". Disabling the treeview fixed this, the network drive was easily browsable afterwards. I also checked with explorer, all network drives and locations were accessible without any delays and the treeview switched on.
So it seems there really is still something left, that makes DO struggle at times. I did not run the ABE-Check tool for all network paths available at work, but for the particular share the collegue of mine had problems with, it did say ABE was not enabled or returned "error".
Question:
Does the ABE-Check tool accept only the share name itself, or can I enter the share-name and a path to a subfolder as well?
The latter is probably not working, and that's maybe why it showed "error" for some of the paths I tried.
Nothing so far suggests any connection to ABE. ABE is rarely used. Might be worth running the checker, but it could be unrelated.
The checker only checks the share, since ABE is turned on or off at the share level. Sub-folders are not relevant to the test it is doing.
My experience with Opus and ABE has never included any periods of unresponsiveness.
Jason
The 11.12.1 beta should make this work now for mapped drives if you'd like to try it (and report back ).
Thanks, I'll check it out and report back.
Jason
I'm sorry to have to report that ABE still doesn't seem to be working with mapped drives. Users still see folders on mapped drives that they shouldn't when the contents of those folders have been changed. As before, anything that causes the file list to refresh does remove them from the list.
There's been no apparent change in Directory Opus 11.12.2 (Beta) x86 regarding ABE when the network share is accessed via a mapped drive letter.
Jason
That's odd. And if you do exactly the same test but with a UNC path it does work ok?
Jon,
Yes, it still works with UNC paths just as it did before. There's been no apparent change regarding mapped drives.
If it would be in any way helpful, we could do an online meeting.
Jason
If you go to one of your mapped drives, select any file or folder, and run the command Clipboard COPYNAMES=unc (you can run it by typing > followed by the command), does the string in the clipboard correctly have the resolved UNC path in it?
Yes, the UNC path is correct.
Here's a sanitized version of what was returned when I just did that using Opus 11.12.2 (from a user account and network share combination subject to ABE, of course):
\fileserver\sharename\WORKL_M\CWORKLOG.EXE
In case it's in any way relevant, the drive letter we're using in this case is E.
Jason
OK, thanks for that. We'll investigate further.
No problem...as I mentioned, if it would be helpful I can do an online meeting from a computer on my network.
Jason