EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Network Mounting Points vs. Old Style Mounting Points

Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.
#8857
Posted: 02/11/2009 15:15:52
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

My application is one that is sensitive to long timeouts as well as having other characteristics that make it a prime candidate for using your new interface for Network Mounting Points.

So, being the intrepid programmer that I am I coded up a version of my application that is sensitive to a registry key entry that I call UseNetworkMountingPoints, and if that key is set, my program uses the new Network Mounting Points APIs instead of the old MountingPoints APIs.

I have run into some issues with the new APIs that make them different then the old APIs. I have gotten used to using the old stuff and in general it works fine for me. The new stuff has some things associated with it that I do not like. I'll enumerate them and let you and the rest of the CbFs world decide whether these are things that I just have to live with, or if they are things you can change.

1. When you add a new Network Mounting Point, in Windows Explorer you see under "My Network Places\Entire Network" a new tree node called "CallbackFS Mounting Points". I do not want to publish the fact to my users that I am using CallbackFS, is there some way for this node to be hidden from the users, or for me to rename it something that is more closely related to my application rather than yours?

2. I add my Network Mounting Points with the following syntax for the Mount Point Name, <Local Mounting Point>;<Server name>;<Share Name>, as is specified in your documentation. I do a AddNetworkMountingPoint call with the MountingPoint name set to "S:;P125252;Srb_S" because I want the drive to be the S: drive on the local system, which has P125252 as its network name and I want other network users to see it there as the share "Srb_S". When I do this and then go do Windows Explorer, I do not see the S: drive anywhere. If I go to Tools, Map Network Drive, I can map the S: drive manually and then it will show up. If I do not do that, it still shows up in the list of drives that I puul down from the Map Drive As combo box on the Map Network Drive screen. I can also go to a Command Line prompt and type in the S: and the command line interpreter will take me to my virtual drive and I can do all the normal DOS commands from there and they all work as expected. Under the old system, when I just added the drive as a regular old Mounting Point, I immediately would see it in Windows Explorer as the S: drive. Why can't Network Drives work the same way? I tried to use the Windows API WNetAddConnection2 to connect the S: drive to the CbFs mounting point, but I got an error code 85 back from that, which means "Resource already connected".

#8858
Posted: 02/11/2009 15:51:37
by Tim Hayes (Standard support level)
Joined: 06/06/2007
Posts: 36

I would like to add my voice to Sid's.

Please, please (a) allow us to put our own network node caption instead of "CallbackFS Mounting Points" and (b) ensure the drive letter appears in Windows Explorer.

Thanks in advance
Tim
#8867
Posted: 02/12/2009 07:32:00
by Volodymyr Zinin (EldoS Corp.)

Hi,

Thanks you for such detail description of the problems.

1. "CallbackFS Mounting Points" is the network provider name and it is tightly associated with the network provider dll and the last one is tightly associated with the driver (this information is written into the registry). And because of a fact that the CallbackFS driver can be used in the same time by several products it isn't possible to change the network provider name.
But I see two workarounds of it:
a) In the next build this name will be more abstract - "Virtual Network Shares".
b) For registered user we can create a custom build. Such build has unique (specified by you) names of the driver and the network provider dll (and the name of the network provider too). But this is a paid service - 15% of the license price. Sure the price includes that custom builds will be done for future versions of the product too.

2. I will check it and think that in the nearest build it will be fixed. There was an another error that perhaps caused this problem (it has been fixed already). The bugfix will be available in several days.
#8933
Posted: 02/17/2009 12:53:06
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Is the bug fix available yet?
#8937
Posted: 02/18/2009 00:43:40
by Volodymyr Zinin (EldoS Corp.)

We are going to make a new build in a few days. I will inform here about it.
#8970
Posted: 02/19/2009 07:38:19
by Volodymyr Zinin (EldoS Corp.)

The new build (version 2.5 RC build 46) is available on the site.
#8981
Posted: 02/19/2009 11:44:34
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Well, I just downloaded and installed the build number 46 and I still have the same problem I described above.

When I mount the S: drive as the share \\P125252\Srb_S, I can navigate to the S: drive at a command prompt, I can see that the S: drive is mapped to the share in the pulldown box under Tools, Map Network Drive, but Windows explorer does not show the S: drive, and if I go to Tools, Disconnect Network Drive, it doesn't show up there as connected either.

I tried using the Windows API WNetAddConnection2 to programattically add the S: drive myself, but I received error code 1223 from that call, which means "User Cancelled Operation", which makes no sense to me.

I am using the flag CallbackFileSystem::nsmAllowMapAsDrive, is that correct?
#8982
Posted: 02/19/2009 11:56:54
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Another thing I noticed is that when I do look at the Tools, Disconnect Network Drive window it shows a connection to the \\P125252 network resource with no drive letter associated with it. It is almost like the call to AddNetworkMountingPoint with the mounting point string set to "S:;P125252;Srb_S" is trying to map the S: drive to the \\P125252 resource instead of the \\P125252\Srb_S share.

Could you clarify for me the exact call that I need to do to have the S: drive show up in Windows Explorer, mapped to the \\P125252\Srb_S share?
#8983
Posted: 02/19/2009 12:34:33
by Volodymyr Zinin (EldoS Corp.)

Quote

... but Windows explorer does not show the S: drive, and if I go to Tools, Disconnect Network Drive, it doesn't show up there as connected either.

Please specify a code snippet that has AddNetWorkMountingPoint call. And what Windows version are you using?

Quote

I tried using the Windows API WNetAddConnection2 to programattically add the S: drive myself, but I received error code 1223 ...

Also please specify a code snippet with this call.

Quote

I am using the flag CallbackFileSystem::nsmAllowMapAsDrive, is that correct?

Yes, it's correct. It means that it is allowed to an user to right click in Explorer on the share and perform "map share as drive".

Quote
Sid Schipper wrote:
Another thing I noticed is that when I do look at the Tools, Disconnect Network Drive window it shows a connection to the \\P125252 network resource with no drive letter associated with it.

It isn't possible to assign a drive letter to "\\P125252". Because "\\P125252" is a virtual server name. The share name in your case is "\\P125252\Srb_S".

Quote
Sid Schipper wrote:
Could you clarify for me the exact call that I need to do to have the S: drive show up in Windows Explorer, mapped to the \\P125252\Srb_S share?

AddNetworkMountingPoint("s:;P125252;Srb_S", TRUE/FALSE, NULL, CallbackFileSystem::nsmAllowMapAsDrive).
#8984
Posted: 02/19/2009 13:25:57
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Here is code snippet. I am using Visual C++ Library Interface with Windows XP.





[ Download ]
Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.

Reply

Statistics

Topic viewed 34320 times

Number of guests: 2, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!