Access denied on network share -- solved by Windows Explorer

[jacksonmacd]

Using XYPlorer 12.40.0200 on Win 7 Ultimate on a corporate notebook and network. This behaviour only started within last 10 days or so. Previously worked properly.

Starting from a fresh reboot, I connect to a network share (mapped to w: drive)
I navigate successfully through a series of folders; the folder appears in XY without any "special icon" on its name, and it is rendered in Black on the folder list. I use Color Filters to indicate the "kind" of folder. Black is "native" - this is a standard folder.

Then return to the root folder of W
A second folder appears with a small "arrow" icon on its name, and rendered in magenta. According to my Color Filters, this is a junction folder.
Try to navigate into this folder -- access is denied. 10 days ago (or so), I could navigate here successfully using XYplorer.

Open Windows Explorer. Navigate to the same folder, and it works properly. No issues.
Return to XYplorer
Navigate to the same folder, and it works successfully.

On a similar issue, I've noticed that many (all?) of the entries that I created in my catalog have partially failed over the last 10 days. They are links to subfolders of the "native" network share that I mentioned earlier. They return a "not found" message when I try to open them the first time. Repeating the double-click on the catalog entry opens them successfully. Thereafter they work properly.

Something has changed recently that makes XYplorer not work well on this corporate network.

Any idea what is causing the problem?

Thx
Jack

[PeterH]

Strange things going on...

Some time ago I reported a problem with .exe and .chm files, when they are located in a folder accessed via a junctioned folder. It seems this problems started several weeks ago with an update of windows (7 X64 SP1 here.)
With the last win update (May 14th, I think) it changed a bit, again. But didn't get better at all...

Situation: if a junction points to a folder, and this folder (not a subfolder!) contains a .exe or .chm, these can't be executed from XY. If they are in a subfolder of the junctioned folder all is OK
(Double click on .txt, .ini or .log is no problem.)

From your report I had the idea, Win explorer might react other way...

Result: double clicking -
- XYplorer.chm or XYplorer.exe from XY shows "Files can't be opened" (German: "Die Dateien können nicht geöffnert werden.")
- XYplorer.chm from Win Explorer: opens an *empty* help page, with no text shown
- XYplorer.exe from WE: starts XY!

So:
- XY and WE react kind of different
- original reason seems to be a change in Windows

Now: what to do??

(For my situation I could move XY folder 1 level down to subdir of the junctioned dir. Works - but I don't like it. And will not be possible in all situations.)

[admin]

Using XYPlorer 12.40.0200 on Win 7 Ultimate on a corporate notebook and network. This behaviour only started within last 10 days or so. Previously worked properly....

Just to make sure: You are not talking about an issue that came about through upgrading XYplorer, but that just emerged out of the blue, and you wonder what could have caused it. Right?

[jacksonmacd]

I am not really sure. I've upgraded with all the recent XY versions. I did not notice the issue last week, and I had *probably* used the folder successfully. I upgraded to 12.40.0200 earlier this week, and probably went for a couple days without using the folder. I isolated the issue yesterday when I definitely used the folder.

It is possible that the folder was a native folder previously, and is now a junction folder. Our IT department may implement such changes without notifying end-users, and I know there have been some recent changes to the folder structure on the network. I never noticed the junction icon previously on the folder, but then again, I never had reason to look for it.

All I can say for sure is that the junction icon is definitely present now on the folder, the issue with XY is repeatable, and the issue does not appear with WE. The issue may have always been there with XY, but just went unnoticed.

The second issue (problem with catalog that is resolved by selecting a second time) was present before 12.40.0200. My guess is that it's been there for about one month. It definitely pre-dates 12.40.0200

Sorry I can't be more specific.

[admin]

Can you determine the junction target, please? XYplorer provides means to do this in the right-click menu of a junction.

[jacksonmacd]

I am currently at a remote location. Connected to the office network via VPN, and the junction folder works properly. I will need to wait until I return to the office tomorrow to try again when I am connected directly to the network.

Not sure how to get the Target on my "office" computer (Win 7-64); the right-click menu has a "Properties" item, but I could not see any reference to "Target". The tabs in the Properties box were: General, Security, Previous Versions, DFS, and Customize. When I tried the same right-click on a Symbolic Link on my home computer (Win 7-32), the Properties box contained a "Shortcut" tab which contained a Target entry.

The folders appear visually identical on the office computer and the home computer.

[admin]

I mean this XY function in the context menu:

[jacksonmacd]

Connected to the office network, and the issue is present again - click on the Junction in the Tree, and XY returns an error that Access is Denied.
However, some "random" sequence of selecting other native folders on the drive, and then back to the junction folder makes it work properly. I haven't isolated an exact sequence that causes it to work properly. Quitting from XY and relaunching it causes the failure again, unless I repeat the action of selecting other native folders.

I do not have a "Junction" item in the right-click menu as is shown in your screenshot.
Went into Configuration, in the Shell Integration section. Noticed that "XYplorer in shell context" was unchecked

Closed XY and re-launched, using Run As Administrator. Opened the Configuration, and checked the XYplorer in shell context. Closed the Configuration. Still no "Junction" item in the right-click context menu. I must be missing something in the Configuration.

When hovering over the folder in the Tree, a popup appears with "Junction: " (however, no path is shown for the junction. There is just the caption title)

Thanks for looking into this issue.

[admin]

To see Junction in the menu ensure that this is ticked:
Configuration | Menus, Mouse, Safety | Context Menus | Custom items in shell context menu

[jacksonmacd]

That menu item was already ticked, but there is nothing on the context menu about junctions.

also, I can modify the contents of the context menu with the "Folder Tree..." button, and have successfully added or removed, say, "Open in other pane". However, the list does not contain anything about Junctions.

[admin]

Note that the Junction item is only present when you right-click a junction. Still not?

[jacksonmacd]

I went to a folder on the local hard drive and created two new items: a Junction to another folder, and a Symbolic link to another folder. Tried the right-click on both of them, and it worked successfully -- the Junction item was displayed on the menu.

Returned to the network share where the folder exists that is causing me the problem. Right-click does not display the Junction item. There is a definite difference between the local drive and the network drive behaviour.

I am *assuming* it is a Junction -- I did not create it myself. It is coloured Magenta, which is defined in my color filters as "attr:junction". When I hover the mouse over the item in the Tree, XY pops up a textbox that *says* it is a junction, but does not provide any additional info (hovermouse.jpg).

[admin]

Cannot reproduce the situation here, but it looks like a rights problem. Did you already try to run XY as administrator?

[jacksonmacd]

Yes, I've run as Administrator

Since I am using a non-standard software in a corporate environment, I don't anticipate getting any support from the IT dept to resolve a rights issue. I will just have to work around the problem -- and that seems feasible by being patient, and trying to access the folder several times. It seems to work after several tries.

Sorry for wasting your time.