Tree of mapped network drive disappears

[admin]

Not here and cannot explain.

Which Windows?

[admin]

OK, I see it now in Windows 11!

[peterbonge]

Is the mapped drive available and connected in that moment?

At home (Win11) I can quickly map a shared drive from a Synology DiskStation at any time. Yesterday I've mapped it shortly before I've tested the problem. So, it was surely available at that moment.
At work (Win10) we have permanently mapped drives from a Windows Server system.

And by the way: If the tree disappears, I can still change folder in the list view with the breadcrumb bar and double-clicking folders. Favorites also still work.

OK, I see it now in Windows 11!

Yeah...

[admin]

Should be fixed in next beta.

[DeeLight]

My latest test was in a Windows 11 VM, but my main PC and the first VM I tested with are both Windows 10.

[peterbonge]

Should be fixed in next beta.

On Win11 I can confirm that it's fixed. Win10 test comes tomorrow.

[DeeLight]

It's fixed for me in Windows 10 as well!!

One weird issue happened somewhere along the way (no idea if it was when upgrading to one of the beta version or downgrading), but all my columns got reset to default, so did the list of available columns in the pop-up menu when you right click to check/uncheck them. I found a slightly older backup that helped me get them back. I'll make a new post if I have time and manage to reproduce this.

[admin]

You mean your custom columns?

BTW, you should always find a backup younger than 24h in <xydata>\AutoBackup.

[daniel_m]

Thanks for fixing this in v26.80.0207.

I too saw the tree becoming weird on my network drive too after I updated to v26.80.0200. On my configuration, creating a new file or copying a file would remove the subfolder + from the tree. On ::fresh; the whole network tree would disappear.
The latest beta fixes all this (Windows 10).

[zmachine01]

I'm having a similar issue. I don't ever have the tree visible, I only use the list views. But occasionally (starting in 26.80.0200) the current tab will randomly return to the base network drive letter or "root" basically. It also does it on the local drive, in my case "C:".. unless the tab is locked. Then what happens is it will open the root drive in a new, unlocked tab. I've tried the fix mentioned earlier but nothing is working. I'm pretty sure there's no kind of action that triggers it. It seems to happen randomly whenever it's in the mood

Windows 10

[admin]

Happens with v26.80.0209 as well?

Also when "Configuration | General | Safety Belts, Network | Network | Assume that mapped network drives are available" is unchecked?

Windows version?

[zmachine01]

Now seems to be fixed in the latest beta

[daniel_m]

Edit: I just noticed that Assume that mapped network drives are available is checked in a ::fresh; instance. Un-checking that option does indeed solve everything I wrote below. Is it still a bug though? It doesn't seem intuitive to me that I have to disable a an option that was enabled by default to have the tree react to copied or deleted folders on a network drive.

Old comment:

The network drive tree is still bugged in v26.80.0303 (on Windows 10).

When I copy a folder on my network drive, that folder does not appear in the tree. Double clicking that folder in the list view does not make it appear in the tree either. The list view does enter the folder correctly, but the tree just greys out. I tested this in my current configuration with all network refresh options enabled, as well as with ::fresh;.

How to replicate:

0) Launch a ::fresh; instance of XYplorer.
1) Navigate to a mapped network drive and create an empty folder, e.g. N:\test\New Folder.
2) Copy that folder to the same location as the original,  e.g. N:\test\New Folder - Copy.
    (It doesn't matter how the folder gets copied: Drag & drop or context menu, as well as copying in the list or the tree view.)
=> The copied folder will not appear in the tree view.
3) Enter the copied folder in the list view.
=> The list view will be at N:\test\New Folder - Copy, but the tree view will not show New Folder - Copy and will grey out instead.

I attached a short GIF to show the behaviour. The colour scheme makes it difficult to see that the tree pane gets greyed out.


Another thing I noticed is that deleting folders on my network drive doesn't remove them from the tree. When I click onto a deleted folder in the tree view, the list view (correctly) says that "The system cannot find the path specified". I think it has been like that for a while now. It doesn't seem to (only) be a problem with Auto-Refresh (all child options enabled!) either.
Manually refreshing the tree with F4, Shift+F4, or F5 doesn't do anything on my network drive. Only resetting the tree with Ctrl+Shift+F4 will make deleted or copied folders visible.

[admin]

Confirmed. I fixed all the things you mentioned (next beta).

I also changed my mind about the default state of "Assume that mapped network drives are available". It's a shame that unavailable mapped drives slow down Windows so much, but working around this and accepting some drawbacks (e.g. wrong icons) should be an active choice by the user.

[Borut]

My settings "Assume that servers are available" and "Assume that mapped network drives are available" are *NOT* checked all the time (and also before the current issues). So I have not experienced the problems described and am not at all complaining in any way.

There is however a detail that is surprising me... In my network I have one server that is permanently switched off. One of the logical drives points to a location on that server. When XY is started (not fresh, but that is here of no importance, I think), the tree appears "at once" (with This PC expanded, so that the logical drives are visible in tree). My unavailable logical drive is immediately shown as unavailable in the tree (red cross at the icon). One or two seconds later the list appears, apparently with some internal initial refreshing. All OK and acceptable. As a result, the logical drives in the list are all shown as available (no red crosses). Another two or so seconds later the red cross appears at the unavailable logical drive in the list. From the handling everything OK - I have no complains (since presumably this is where some Windows network enumeration or so is waited upon).

It is just that I do not understand how the totally correct situation is depicted in the tree at once, while for the list some additional things (and a few more seconds) are apparently required to achieve the same result.

Again: Not complaining, just wondering...

Edit: Tested it more... It is probably about fetching the drive type, because - in the list - at the moment the availability is revised (the red cross appears) also the "new" type information appears: "Nichtverbundenes Netzlaufwerk".