Map network drive in Explorer - not in XY!

[petersboulton]

Hi,

I mapped a network drive in Windows Explorer, which was successfully created, but it does not show in XYplorer, even if I close and restart XYPlorer. If I create it through the Tools menu in XYplorer then it is available in XYplorer.

On the other hand, if I disconnect the mapped drive in XYplorer and Windows Explorer and use the Tools/Map network drive option in XYplorer it shows in XYplorer but not in Windows Explorer!

Am I misunderstanding what XYplorer is doing? If I use the menu option in XYplorer should the mapped network drive be visible to all apps or just in XYplorer? Surely the intended functionality is that creating a mapped network drive in XYplorer or Windows Explorer has the same result - i.e. drive visible throughout, including in XYplorer?

I've attached a screenshot of the first case I described - i.e. create mapped network drive in Windows Explorer. The mapped drive is actually a shared folder on the same computer, but I don't think that should matter. So, is this a bug or my misunderstanding?

Thanks,

Pete

[petersboulton]

Please could I give this issue a 'nudge' as I am still seeing the same behaviour on mapped drives.

I actually first raised it in http://www.xyplorer.com/xyfc/viewtopic.php?f=2&t=4291 back in November 2009. I am nothing if not patient!

Can you replicate the problem I'm seeing on mapped network drives in Win7? (I don't think it can be a problem with my Windows 7 as I'm now on a different installation from when I previously reported these issues but am still experiencing the same issues!).

Thanks.

Pete

[admin]

64 bit Windows?

[petersboulton]

64 bit Windows?

I am now, yes, but preciously when I reported this issue I was on 32 bit.

Pete

[petersboulton]

Hello,

Are there any plans to fix this long-standing bug and if so, on what timescale? Sorry to be pushy but I feel this bug has been ignored for a long time, is relatively serious and I cannot be the only person who is affected by it.

Regards,

Pete

[admin]

I would fix it today if I had any idea how.

[petersboulton]

I would fix it today if I had any idea how.

Hmmm. OK, to start with there are 2 bugs: first, XYplorer does not pick up when a mapped drive is created in Windows Explorer and second, Windows does not pick up a mapped drive created by XYplorer.

On the first one, where the mapping is created in Windows Explorer, the mapped drive is instantly picked up by any subsequent file open dialog (for example). Therefore clearly the new drive letter just comes into existence at some point and it should not be rocket science for XYplorer to 'notice' the new drive, given it notices file changes etc. just fine. So I don't think there is any Windows alchemy required to pick up a new drive letter mapping - it should be picked up be a timer or whatever other mechanism you already use to detect file changes in real(-ish) time.

In terms of XYplorer creating the mapping and it not being detected in Windows, are you using WNetAddConnection3 at http://msdn.microsoft.com/en-us/library ... s.85).aspx or similar? This function is part of Windows API and if you are using the right parameters I guess should work just fine. Of course, I have no idea what your current code is using - maybe the 'wrong' api?

Have I now spent longer thinking about how to solve this problem than you have? Because I think it should be solvable and the bug has been outstanding for a rather long time. Please?

I hope my suggestions are helpful / will give you some pointers.

Pete

[admin]

I would fix it today if I had any idea how.

Hmmm. OK, to start with there are 2 bugs: first, XYplorer does not pick up when a mapped drive is created in Windows Explorer and second, Windows does not pick up a mapped drive created by XYplorer.

On the first one, where the mapping is created in Windows Explorer, the mapped drive is instantly picked up by any subsequent file open dialog (for example). Therefore clearly the new drive letter just comes into existence at some point and it should not be rocket science for XYplorer to 'notice' the new drive, given it notices file changes etc. just fine. So I don't think there is any Windows alchemy required to pick up a new drive letter mapping - it should be picked up be a timer or whatever other mechanism you already use to detect file changes in real(-ish) time.

In terms of XYplorer creating the mapping and it not being detected in Windows, are you using WNetAddConnection3 at http://msdn.microsoft.com/en-us/library ... s.85).aspx or similar? This function is part of Windows API and if you are using the right parameters I guess should work just fine. Of course, I have no idea what your current code is using - maybe the 'wrong' api?

Have I now spent longer thinking about how to solve this problem than you have? Because I think it should be solvable and the bug has been outstanding for a rather long time. Please?

I hope my suggestions are helpful / will give you some pointers.

Pete

Sorry, but you probably have not spent longer thinking on this than me. The network functions in XY are a result of years of work. And, please don't think a quick look into MSDN brings up a ready-made solution. It could work, it could not work. So when I say "I would fix it today if I had any idea how." I mean it.

[petersboulton]

I would fix it today if I had any idea how.

Hmmm. OK, to start with there are 2 bugs: first, XYplorer does not pick up when a mapped drive is created in Windows Explorer and second, Windows does not pick up a mapped drive created by XYplorer.

On the first one, etc.....

Pete

Sorry, but you probably have not spent longer thinking on this than me. The network functions in XY are a result of years of work. And, please don't think a quick look into MSDN brings up a ready-made solution. It could work, it could not work. So when I say "I would fix it today if I had any idea how." I mean it.

Sorry, but your "I would fix it today if I had any idea how" came across as implying you weren't really that bothered about fixing it.

I accept that you have probably spent longer thinking about it than me. However, for example, given that a mapped drive letter just 'appears' as a drive letter to Windows I can't really understand why XYplorer cannot detect it. It seems relatively simple - and by the way, I am a (full time, self-employed) software developer myself so I understand the difference between simple and difficult!

Also, I believe the behaviour I reported occurs on Vista and Windows 7 only, not XP or previously. Therefore although the network functions may have been "a result of years of work" I would humbly suggest that maybe they need to be revisited in the light of changes to Windows in recent versions?

I guess I will just have to accept that you ARE taking the issue seriously and that I misunderstood your original response. Equally, if you ARE taking it seriously I hope some time can be allocated to it soon in order to resolve the issue, as I doubt very much that resolving it is actually impossible.

Finally, I have sung XYplorer's praises in almost every previous post I've made and also to friends and business contacts. I hope you will see this thread against that history.

Thanks.

Pete

[admin]

Ok Pete, sounds much better. It's on my list for revision.

[admin]

OK, I tested both actions under Win7/64, and both were successfull:

1) map network drive using WE: it shows in XY immediately without problems.
2) map network drive using XY: it shows in WE immediately without problems.

Hm. Was there a misunderstanding?

[petersboulton]

OK, I tested both actions under Win7/64, and both were successfull:

1) map network drive using WE: it shows in XY immediately without problems.
2) map network drive using XY: it shows in WE immediately without problems.

Hm. Was there a misunderstanding?

No misunderstanding. I apologise - I tried these scenarios on a Win 7 64 bit virtual machine and on that basis XYplorer is definitely innocent! (As in, working correctly.)

In trying to understand what causes it to work on my virtual but not work on my host the only difference is that I run XYplorer on the host as Administrator whereas on the virtual it's running in User mode.

So maybe I owe you an apology, at least partial! However, if I run Windows Explorer as Administrator on my host machine (the one about which I reported the problem originally), create a mapped drive in that instance, and then launch another Windows Explorer as User the mapped drive does appear correctly (and also in all file-open boxes in any application).

Therefore, if you wish XYplorer to behave similarly to Windows Explorer (in this instance that seems reasonable) then there is still an issue with XYplorer - I can create a mapped drive as Admin in Windows Explorer and the User processes see it, whereas that doesn't happen when I create the mapped drive in XYplorer/Admin.

For what it's worth, I recorded a screen demo of XYplorer running in Admin mode here so you can see the originally described behaviour is not a figment of my imagination:

http://www.dataper.demon.co.uk/xyplorer/

(The movie runs in your browser - no installs needed etc..)

I guess the correct behaviour should be that mapped drives, created via Admin or User mode should appear to all applications running (in the same login identity) on that desktop irrespective of which mode they are running in, providing that the Admin mode is associated with the current user's SID. As that's what Windows is doing.

I hope this gives you enough information to diagnose and I'm sorry I didn't spot the complication of XY in Admin mode previously.

All the best,

Pete

[nas8e9]

@petersboulton: I've taken a look on my computer (i.e. a physical host rather than a VM) to see what happens when creating a drive mapping in an elevated instance of XYplorer, and it seems to work as expected: the drive mapping immediately shows up in a non-elevated instance of Windows Explorer.

In all, I don't seem to have your problem. From your screenshot I see that you're running a fairly old XYplorer version; could you try the latest beta and also with a clean profile by copying just XYplorer.exe and XYcopy.exe to an empty folder and running XYplorer.exe from there?

Do you have SP1 for Windows 7 installed and what security software do you use?

@Don: Trivial problem, but one oddity is that an elevated instance of XYplorer doesn't pick up the new mapping created through Tools > Tools Special > Map Network Drive, while a non-elevated instance does. Mappings created by either a non-elevated Windows Explorer instance as well as through an elevated command prompt, are picked up immediately. On manually refreshing the Tree, the mapping does become visible when it initially doesn't.

Windows 7 x64 SP1 / XYplorer 10.20.0003 beta / Kaspersky Internet Security 2012.

[petersboulton]

@petersboulton: I've taken a look on my computer (i.e. a physical host rather than a VM) to see what happens when creating a drive mapping in an elevated instance of XYplorer, and it seems to work as expected: the drive mapping immediately shows up in a non-elevated instance of Windows Explorer.

My screen movie clearly shows that what appears to work for you does not happen on my computer (i.e. physical host).

In all, I don't seem to have your problem. From your screenshot I see that you're running a fairly old XYplorer version; could you try the latest beta and also with a clean profile by copying just XYplorer.exe and XYcopy.exe to an empty folder and running XYplorer.exe from there?

You are mistaken. My movie shows V10.20 of XYplorer, the latest official version. (Betas aren't for me.) You may be looking at one of my earlier posts from some time ago. So maybe you are not replicating what I found because you haven't followed the steps in my movie?

Do you have SP1 for Windows 7 installed and what security software do you use?

Yes, my Win7 is fully up to date and I use MSE.

@Don: Trivial problem, but one oddity is that an elevated instance of XYplorer doesn't pick up the new mapping created through Tools > Tools Special > Map Network Drive, while a non-elevated instance does. Mappings created by either a non-elevated Windows Explorer instance as well as through an elevated command prompt, are picked up immediately. On manually refreshing the Tree, the mapping does become visible when it initially doesn't.

Windows 7 x64 SP1 / XYplorer 10.20.0003 beta / Kaspersky Internet Security 2012.

I don't view the problem as trivial. However, clearly there are a variety of permutations here which makes it harder to resolve. Can we agree that clearly not all the permutations work correctly? (Otherwise my movie would show working drive mappings!)

I feel my movie establishes the case that all is not working 100% with this feature. I hope my delayed realisation that the running as Admin vs. User explains why you weren't able to reproduce my findings (@Don) and hopefully you now can.

[nas8e9]

In all, I should have gone to the movie...

If I've read the entire thread correctly, the remaining problem is the inability of WE to see a mapping created by an elevated instance of XYplorer. That scenario I've tested in the same way as your movie shows, without getting your problem.

@Don: Trivial problem, but one oddity is that an elevated instance of XYplorer doesn't pick up the new mapping created through Tools > Tools Special > Map Network Drive, while a non-elevated instance does. Mappings created by either a non-elevated Windows Explorer instance as well as through an elevated command prompt, are picked up immediately. On manually refreshing the Tree, the mapping does become visible when it initially doesn't.

Windows 7 x64 SP1 / XYplorer 10.20.0003 beta / Kaspersky Internet Security 2012.

I don't view the problem as trivial. However, clearly there are a variety of permutations here which makes it harder to resolve. Can we agree that clearly not all the permutations work correctly? (Otherwise my movie would show working drive mappings!)

I'd hoped to clearly delineate the two parts of my post: there's a separate, small refresh problem which I wanted Don to know about and which I deemed trivial, separate from your problem, which I wouldn't describe as such.