EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Network Drives

Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.
#6257
Posted: 05/14/2008 16:21:25
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I have already implemented an application that creates a Virtual Drive that is an interface to my database system. It uses the AddMountingPoint to add a drive letter, let's say for discussion's sake that the drive letter is S:. In Windows Explorer, I was able to right click on the S: drive and set up sharing in such a way as to be able to share my virtual drive over my network. This all worked fine.

I was quite happy to see in version 2.0 the AddNetworkMountingPoint function that seemed to be something similar to what I was already doing. The parameter ShareName, seemed to be the share name that I was using Windows Explorer to set up, so I thought that AddNetworkMountingPoint would automatically set up the share for me and by using it I could eliminate the manual step of having to set up the share with Windows.

I got a little scared when I read the documentation closer and saw that you recommend setting the ShareName parameter to NULL. Why would you do that?, I asked myself, it defeats the whole purpose of what I wanted to do.

But, I tried it out anyway, by installing the Network Redirector Helper DLL and using AddNetworkMountingPoint instead of AddMountingPoint.

When I did that, many things happened that were not good for me. First of all the name of the drive was now "Network Drive", instead of the drive name I provide in the GetVolumeName callback. And, worse than that, the drive is not shared, as I expected it to be, and if I try to share it using Windows Explorer, I cannot because the "Sharing and Security..." choice doesn't exist on the Windows Explorer context menu, where it should be.

I know AddNetworkMountingPoint will give me many performance benefits that I do not have now, but if, as you say in the documentation, it is supposed to expose the drive to the network, it doesn't seem to be working as designed and therefore, I must go back to using AddMountingPoint and manually sharing the drive through the Windows Explorer interface.

Am I doing something incorrectly. I hope so, because I really wanted to be able to use this new interface.
#6262
Posted: 05/15/2008 01:02:59
by Eugene Mayevski (EldoS Corp.)

AddNetworkMountingPoint does not create a share for you. All it does is make the virtual disk look as network for Explorer, in order for Explorer not to read the thumbnails from all files.
As this is a network drive already, you can't share it.


Sincerely yours
Eugene Mayevski
#6263
Posted: 05/15/2008 01:33:44
by Volodymyr Zinin (EldoS Corp.)

Quote
Sid Schipper wrote:
I got a little scared when I read the documentation closer and saw that you recommend setting the ShareName parameter to NULL. Why would you do that?, I asked myself, it defeats the whole purpose of what I wanted to do.

ShareName is the name of a virtual nonexistent share to which a network mount point connected. The only purpose of it is to display this name near the network drive letter in Explorer. But currently it isn't shown there.
#6264
Posted: 05/15/2008 01:37:14
by Volodymyr Zinin (EldoS Corp.)

Quote
Sid Schipper wrote:
And, worse than that, the drive is not shared, as I expected it to be, and if I try to share it using Windows Explorer, I cannot because the "Sharing and Security..." choice doesn't exist on the Windows Explorer context menu, where it should be.

Windows doesn't allow sharing of network disks.
#6291
Posted: 05/16/2008 07:35:32
by Robin Astle (Basic support level)
Joined: 04/15/2008
Posts: 30

Quote
Vladimir Zinin wrote:
...The only purpose of it is to display this name near the network drive letter in Explorer. But currently it isn't shown there.


Will this be in the final release of cbfs 2.0? Or when is this planned?
#6306
Posted: 05/19/2008 02:13:24
by Volodymyr Zinin (EldoS Corp.)

It won't be in the final release. And I don't know when it will be implemented, but we're going to do this.
Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.

Reply

Statistics

Topic viewed 3662 times

Number of guests: 1, 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!