EldoS | Feel safer!

Software components for data protection, secure storage and transfer

High priority request: user defined volume GUID

Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.
#23281
Posted: 01/21/2013 11:38:41
by Brahim Bakayoko (Standard support level)
Joined: 11/22/2011
Posts: 37

Right now, CbFS volumes don't have a stable GUID which causes issues such as Windows not remembering shares created on those volumes.

The option should be given through the API to set the GUID for each volume.
This will allow the application to set the same unique GUID the given volume and allow Windows to properly remember the volume too.

This is of a critical priority and should be trivial to add to the API.

Thanks.
#24390
Posted: 03/31/2013 07:39:04
by Brahim Bakayoko (Standard support level)
Joined: 11/22/2011
Posts: 37

Hi,

I wanted to follow up on this request.
I have not tested CbFS 4 with the new PnP stack, but wanted to get any response on whether a disk with the same Volume Serial Number would get the same GUID.

This is important so that shares defined on the virtual storage disk don't get lost after a system reboot.

Thanks.
#24404
Posted: 04/01/2013 12:25:51
by Volodymyr Zinin (EldoS Corp.)

I have tried the following:
1. Created a nonPnP disk with the "E:" drive letter mounting point, which was created with the CBFS_SYMLINK_MOUNT_MANAGER flag.
2. Created there a folder with name "1".
3. In Explorer right-clicked on the folder and created a "microsoft networks" (SMB) share.
4. Deleted the virtual disk.
5. The share remained in the system (it was visible in the "computer management" console, see the attachment).
6. Recreated a virtual disk (it doesn't matter whether it's PnP or non-PnP) with the same drive letter (E:).
7. The share still worked.

Maybe I misunderstood you. Please describe in details the problem and how to reproduce it.
Thanks.


#24405
Posted: 04/01/2013 13:13:45
by Brahim Bakayoko (Standard support level)
Joined: 11/22/2011
Posts: 37

Hi Vladimir,

The issue is with losing the share after a system reboot.

So, here is the test to try:
- Create a share on the virtual drive
- Add share permissions
- Test that it is accessible from another computer
- Reboot
- Try to access the share again

Windows simply remove shares created on devices with no stable GUID on reboot.

Thanks.
#24407
Posted: 04/02/2013 03:42:00
by Volodymyr Zinin (EldoS Corp.)

"Microsoft networks" (SMB) service saves information about shares in the registry in the key "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\services\LanmanServer\Shares". And it associates a share name with a drive letter (not with a volume GUID mounting point). For example:
"share_name" -> "E:\shared_folder_name"

So if you insert a USB removable flash drive, create a folder there, and share it. Then remove the drive, reboot the machine, and insert another disk with a folder with the same name. In this case the system recreates the share, but it will point not to the original folder.

For CallbackFS virtual disks shares are also saved by Windows. But the system doesn't recreate them because CallbackFS disks are created not in the "standard" way, that somehow influences on Windows not to recreate shares. I.e. at first a virtual storage is created without a "media" inside it and automatic creation of a drive letter is "suppressed", then a "media" is inserted (the MountMedia call it performed) and a mounting point is created.
#24410
Posted: 04/02/2013 03:50:57
by Volodymyr Zinin (EldoS Corp.)

A little more - Windows recreates shares only for "non-removable" drives. I.e. that drives that doesn't specify the special "removable" flag. Some flash drives as well as some external disks don't specify it and only for such disks shares will be recreated.
#24420
Posted: 04/03/2013 02:56:59
by Brahim Bakayoko (Standard support level)
Joined: 11/22/2011
Posts: 37

Vladimir,

Thanks for the insight.
It still remains that shares created on fixed CbFS virtual drives are not reconnected by Windows.

How can we resolve that issue?

In fact, can we also have the option of not suppressing the automatic recreation of the drive letter?

Currently, re-creating the shares from the client application only works for simple shares and requires extra setup and management, which gets messy very quickly.
#24422
Posted: 04/03/2013 04:42:38
by Volodymyr Zinin (EldoS Corp.)

Quote
Brahim Bakayoko wrote:
It still remains that shares created on fixed CbFS virtual drives are not reconnected by Windows.

The reason of this problem I described above. We have added it to our todo list and will examine it deeply in order to check what is possible to do with it.

Quote
Brahim Bakayoko wrote:
How can we resolve that issue?

Just to manage shares in your code.

Quote
Brahim Bakayoko wrote:
In fact, can we also have the option of not suppressing the automatic recreation of the drive letter?

Currently there is no such option. This question has also been added to the todo list and perhaps it will be implemented.
#24438
Posted: 04/03/2013 10:54:00
by Brahim Bakayoko (Standard support level)
Joined: 11/22/2011
Posts: 37

Thanks for adding it to your TODO list.

I would like to stress that this is a critical issue for my implementation.
So hopefully, you will give this a higher priority.

Thanks a great deal for the support.
#25890
Posted: 07/30/2013 10:44:37
by Volodymyr Zinin (EldoS Corp.)

Implemented. It will be available in CallbackFS v5, which is expected in the autumn.
Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.

Reply

Statistics

Topic viewed 4469 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!