EldoS | Feel safer!

Software components for data protection, secure storage and transfer

CBFS 2.5 beta & Network Mount Points

Posted: 02/04/2009 08:30:01
by Ian Colomby (Priority Standard support level)
Joined: 11/14/2008
Posts: 25

I've downloaded the new beta of the Callback File System (v2.5) and I'm trying to use the new network mounting point functionality to mount a UNC path, but I'm noticing a discrepancy between the docs and the assembly and I'm not sure how to mount the network share properly.

The HTML documentation says the API call for AddNetworkMountingPoint takes 5 parameters: mount point, share name, local link, LUID, and flags. But when I try using that call in my code the AddNetworkMountingPoint only takes 4 parameters, mount point, local link, LUID, and flags -- no share name.

So, I'm not sure how to mount the network without a share name.

I'm using the .NET version of the assembly and C# with VS2008.

Thanks, Ian.
Posted: 02/04/2009 09:35:49
by Vladimir Cherniga (Team)

MountingPoint parameter must have the following format:
Link_name can be empty (in this case access will be possible only via UNC path like "\\server_name\share_name")
Server_name and share_name specify virtual server and share names for the link.

We will fix the documentation shortly.
Posted: 02/05/2009 09:18:45
by Eugene Mayevski (Team)

Here's the detailed description of the new syntax.

Sincerely yours
Eugene Mayevski
Posted: 02/05/2009 12:04:57
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Also, something that is not very clear in your documentation is that the flags must be specified with a context identifier or with an instance of a CallbackFileSystem object, because your enum for them is within the class declaration. So using just nsmAllowMapAsDrive will give you a compiler error. You must use either "CallbackFileSystem::nsmAllowMapAsDrive" or
"pCbFs->nsmAllowMapAsDrive", where pCbFs is a pointer to an instance of a CallbackFileSystem object. It would be nice if this was specified in the documentation, so I wouldn't have to figure it out by myself. :-)
Posted: 02/05/2009 15:57:06
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

OK, I'm having some trouble with this also. I use the Visual C++ Library interface on a Windows XP system.

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".

The other parameters in my call are set to FALSE for the local link parm and NULL for the AuthId parm and nsmAllowMapAsDrive for the flags.

In the debugger, the call seems to work OK. But when I try to use GetMountingPointEx, to see the CbFs connection, it gives me a windows exception. Strangely, if I use the old API GetMountingPoint, it works. I have the parameters to both functions set up identically and that may be the problem, because in your documentation the old API takes an int as its first parameter, while the new API takes an unsigned short *. Now, I believe that doc is wrong because when I look in the CbFs.h file, the prototype for the new API does take an int as its first parameter. So, I am thoroughly confused.

Aside from that, the drive letter S: doesn't show up in Windows explorer unless I map it explicitly. This means that programatically I must do a WNetAddConnection2 call to get the S: drive to show up. Is that true? I would have expected CbFs to do that for me.

I have installed the VSNetRdr.dll as your instructions told me to, as well as the VSMntNtf.dll, so I don't think that is the problem. It probably is just something I don't understand about network drives. Can anybody out there help me, please?
Posted: 02/06/2009 08:52:20
by Vladimir Cherniga (Team)

because in your documentation the old API takes an int as its first parameter, while the new API takes an unsigned short *.

This is error in documentation. It will be fixed. The right declaration for this function is next:

BOOL GetMountingPointEx(INT Index, LPBOOL LocalLink, LPBOOL NetworkLink, PLUID AuthenticationId, LPWSTR* MountingPoint);

I have tested this api and it works without any objections. Could you provide a code snippet that illustrate the situation when exception was raised.
Posted: 02/06/2009 11:57:05
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I am attaching the source code for the subroutine that gets the Windows exception. The exception occurs at line number 43. There is a lot of stuff in there that you should probably ignore, but you'll notice that at line 45 there is a call to the old API and it is done depending on the truth or falseness of the variable "theApp.UseNetworkMountingPoint". Well, when I set that variable to false, all my code uses the old APIs and everything works fine, but when I set that variable to true, everything uses the new network APIs and thats when I get the exception.

You may need more code, since the calls that set everything up (i.e. AddNetworkMountingPoint, etc.) are done elsewhere. Let me know and I'll be glad to provide you with anything you need.

[ Download ]
Posted: 02/06/2009 12:08:16
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Oops!, after sending you the code, I looked at it more closely and I think I see the reason for my error. The old API creates the MountingPoint string for you and you have to free it after calling GetMountingPoint. The new API uses whatever buffer you send it and doesn't create a new string, so when I free the old string like I do for the old API, on subsequent iterations of my for loop that memory is no longer there for the new API to use. I'm pretty sure, although I haven't tried it yet, that removing the delete for the string pointer will solve my problem. If that is the case, I still think you need to make it clear in your documentation how the subroutines handle that string parameter differently.

It is fine for all you newfangled guys using .NET because the system does garbage collection for you, but for us old dinosaurs, :-) who still manage our own memory we need to know whether or not we need to free up memory that possibly has been allocated for us by subroutine calls.
Posted: 02/06/2009 12:28:20
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Oh, well, my speculation above was not true. I took out the free of the memory area for the MountingPoint string and I still got the Windows exception. It was on the very first iteration of my loop, so I was all off-base with my second analysis.

The interesting thing is that in the debugger that string area shows up with the correct string that I would expect it to have if the call to your subroutine had really worked, even though the exception occurs and the call stack has me in the code as follows;

vdiskService.exe!_CbFsGetSymLinkEx@28() + 0xf9 bytes
vdiskService.exe!CallbackFileSystem::GetMountingPointEx() + 0x7c bytes

So, it is almost like your subroutine does everything correctly until it reaches the _CbFsGetSymLinkEx@28 subrotuine at which point something goes haywire.

Posted: 02/09/2009 03:08:54
by Vladimir Cherniga (Team)

Thank you for the code snippet. As i can see from sources you have allocated memory for the MountingPoint parameter. But this is done internally by the..Ex api too. You shouldn't allocate memory, only free it in the case of successful call to the GetMountingPoint(Ex). And the last but not least thing. Even if you don't support AuthID parameter you must offer a storage for this value when you invoke GetMountingPointEx api. So i think the part of your code should look like this:
LPWSTR MountingPoint = NULL;
BOOL LocalLink, NetworkLink;

GetMountingPointEx(Index, &LocalLink, &NetworkLink, &AuthID, &MountingPoint)



Topic viewed 15349 times

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


Back to top

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

Got it!