EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Getting the drive letter

Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.
Posted: 08/25/2008 15:27:18
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I did a search in this forum and I couldn't find an answer to the following question.

Suppose I use AddMountingPoint to add two different mounting points to the same storage, for example, an S: and a T: drive. I then go to Windows Explorer and click on either of those drive letters, which triggers a call to the OnEnumerateDirectory callback. In that callback routine, how can I determine which mounting point (or as I see it, drive letter) has triggered the callback?

In other words how do I know if I clicked on the S: drive or the T: drive?
Posted: 08/26/2008 00:10:57
by Volodymyr Zinin (EldoS Corp.)

Currently it's not possible. But it can be implemented in future. Why are you want this?
Posted: 08/26/2008 10:54:44
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

To explain why I want this I need to give you some background into my application. We have a storage management system that presents to the user a drive that is in reality files that our system maintains across various different storage devices, so our drives are really "virtual drives" and I use your callback file system to do the necessary calls to my system to handle user requests.

When I set up the virtual drive for the user, I log in to my storage management system as that user and the storage managemnt system has its own authorization and authentication mechanisms for each user. For example, one user may have the permissions within our system to see all of the other users files, while another user may have access to only the files that he owns.

We want to be able to give users the capability to set up different drive letters that map to different users of our system, if they have the credentials to log in as those users. So, for example, the S: drive might be for the "sid" user, while the T: drive might be for the "vladimir" user, if I have a Windows user account that knows the credentials on our system for both of those users.

If I implemented such a thing you can see why knowing the drive letter is important, since I wiould have to send the correct userid or some other identification of the user session that is represented by that drive letter to my system whenever I make the calls that handle the user requests.

If you can think of some other clever way of doing what I am trying to do, I'd appreciate it, but finding out the drive letter was the only way I could come up with.
Posted: 08/26/2008 11:02:13
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I also thought that maybe I could use enumeration contexts or some other user mechanism that you provide to map Mounting Points to users, but it didn't seem like the AddMountingPoint interface allowed for establishment of some user context that I could then use in the callbacks.
Posted: 08/26/2008 11:59:56
by Eugene Mayevski (EldoS Corp.)

Thank you for detailed description. You can't have different views of a single object. If the disk is enumerated and the certain directory is reported to have 3 files each being 1 Kb large, then you can't report 2 files being 2 Kb large for the other mounting point.

You should use different CallbackFileSystem objects for all of the views. In this case each CallbackFileSystem object has it's own mounting point and it's own representation in the system.

Sincerely yours
Eugene Mayevski
Posted: 08/26/2008 17:59:14
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Thank you, Eugene. Your idea of using different CbFs objects for each view works very well.
Also by EldoS: SecureBlackbox
200+ components and classes for digital security, signing, encryption and secure networking.



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