I meant to point out that Windows Explorer never shows the folders that users don't have access to when access based enumeration is enabled. That's the reason I was surprised to find that Opus was showing them sometimes. It never occurred to me that it would do that until I saw it happening.
Unrelated point: it would be great if posts could be edited by the poster. I don't see any way to edit a post once it's made.
Jason
Further clarification: I only expect Opus to respect access based enumeration as much as Windows Explorer respects it.
Jason
In the next update we'll fix this problem (that is, file change notification causing folders that should be hidden to appear in the file lists). Note that Opus 10 is no longer being updated so this fix will only be in Opus 11.
Awesome! So you're thinking it should be addressed Opus 11.8?
Thanks.
Jason
Yes most likely, however there'll be a beta released before then if you want to try it earlier.
Thanks!!!...I just noticed that today when I got an alert about 11.7.3.
Installing the latest release on my own PC now to check it out. Thanks for the quick handling of this. I'll let you know if find any apparent problems.
Jason
Sorry, I have been meaning to update this topic for quite a while now.
Is it expected that ABE is functional in Directory Opus 11.10 (that's the version I'm currently on)? I'm still seeing that when the contents of folders that people don't have access to are changed those folders are listed in the File List window until that window is refreshed. This seems to be exactly what was happening before ABE was added to Directory Opus in an earlier Directory Opus 11 update.
I look forward to your reply,
Thanks,
Jason
Out of curiosity, does your network use Distributed File System namespaces? If so, ABE isn't enabled by default on DFS namespaces. msdn.microsoft.com/en-us/librar ... px#BKMK_UI
I don't use DFS. ABE is enabled on the shares. The problem I'm still having is described in the earlier posts.
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