C / C++ / MFC

27-Dec-10 3:41

Hello folks!

I have a small project in mind which would involve creating virtual files/folders on a client's computer (preferably without needing admin rights too). My first thought was to create a shell extension, however, here[^] MSDN doesn't list anything like virtual folders or files. Then i moved on to creating a File System Minifilter Driver[^], but this seems to be overkill for this purpose only. After some googling i came accross the Installable File System kit[^], but checking it on Microsoft's site i found this:

If you are trying to create virtual files or directories to be viewed through the Windows Shell, the shell extension interfaces may be a better option. Shell extension modules are user-mode DLLs that are registered with the Windows Shell. For more information on these interfaces, please refer to the Platform SDK section of the MSDN Online Library.

.
So now i am confused, it suggests to use shell extensions, however, shell extensions doesn't seem to provide this functionality...where did i go wrong? Anyone can give me some pointers, please? Thanks in advance...

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
>Nothing is free in the universe.<

cmk27-Dec-10 8:46

27-Dec-10 8:46

I've been looking into a similar thing.
The best I've come up with so far is Doken[^].
They have developed the kernel driver and expose a user API to develop your own filesystem apps.
Others have already developed both ram and file based filesystems[^] for it.

The minifilter option provides filesystem access for _all_ applications, shell extensions are only for accessing files through, well, the shell e.g. explorer.

It comes down to how will the client need to interact with your filesystem ?

...cmk

The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack

Code-o-mat27-Dec-10 9:51

27-Dec-10 9:51

Thanks for your reply. This is what i'd like to do: the user would "mount" the filesystem on his computer by running a small program or somesuch. A new drive would appear on his system or a new folder would pop up on his desktop (i'd prefer the new drive as if an USB storage device had been connected). Either way, i will call this the "root". So under the root, some folders and files would appear. The content of some folders and files the user should be able to modify, some not. For example he should be able to edit some files, but not delete them, he should also be able to open some files for reading but not save them (he can save them to a different location if he wishes to of course but not overwrite the originals), he should be able to add new files in some folders or delete them, but not be able to do the same in some other folders. Here comes the more tricky part: these files and folders don't really exist on the user's computer, hence, "virtual files and folders". The files' contents are generated/converted on-the-fly, what i mean is, the user e.g. sees abc.doc on the drive, opens it with Word, the system, "behind the scenes", generates the doc format data from other kind of data that might come from a database or another file, etc., the user edits the contents and when he saves it, the doc is converted back to the original data format and stored back into the database or to the other file or wherever it came from (also, possibly over a network/internet).
I really suck at explaining things but i hope it's clear what i mean. I guess i will have to dig deep into writing a file system driver if i want to make anything of this. I will check out that Dokan, looks promising.

cmk27-Dec-10 11:00

27-Dec-10 11:00

I believe I understand, it's similar to what I'm looking to do - be able to mount new drives that expose filesystems stored in a database.

I think Doken will be the easiest and most flexible solution.
If you look through the source of the ones implimented on their site you'll see it's not too bad.

Code-o-mat27-Dec-10 11:05

27-Dec-10 11:05

Thank you for the help and good luck with your own project.

Code-o-mat29-Dec-10 5:22

29-Dec-10 5:22

When looking at shell namespace extensions (which can't serve this purpose) i came across another idea, faking a remote filesystem that can be mounted as a network drive. Doing this seems to be less troublesome than writing a file system driver from scratch, am still trying to evaluate this idea, might or might not work, i just thought i mention it since you said you are looking for something similar too.

cmk29-Dec-10 10:04

29-Dec-10 10:04

As far as I can tell, you have to write code to handle file CRUD requests no matter how you do it ... six of one, half-dozen of the other.

So far the Dokan still looks easiest, it looks like the main dev points are:
1. Write thread-safe functions specified in DOKAN_OPERATIONS e.g. CreateFile, ReadFile, ...
2. Pass an instance of DOKAN_OPERATIONS with pointers set to your functions, and DOKAN_OPTIONS with info on how you want to mount your FS, to the driver via DokanMain. This will also mount your FS.
3. Call DokanUnmount when done with FS.

I still have to work through the nuances of mounting/unmounting via: my app, dokanctl, dokan mounter, ...

Notes:
- Although Dokan comes with both x86 and x64 drivers, it looks like the user dll is x86. This means your app must be compiled for x86.
- The Dokan API does support files > 2GB.
- Test your app FS in a virtual machine, if you made a mistake it can totally hose your system.

Code-o-mat29-Dec-10 11:03

29-Dec-10 11:03

I have two concerns about Dokan:
-you have to install its driver as administrator
-even when you do not use it for anything it still lingers around

I guess these are minor concerns though. I read some SMB (NetBIOS) specs and realized it indeed seems to be way way too complex for this.

cmk29-Dec-10 11:16

29-Dec-10 11:16

The fact that it's open source alleviated any concerns about installing as admin ... or do you mean concerns for deploying to your customers ... yes, I could see that being an issue.

I don't think it uses much when idle ... on my machine the mounter service is using 928KB, 71 handles, and 4 threads with no FS mounted.

I am more concerned about the fact that it's open source means I have no idea how rigorous the testing has been on the code; however, it seems to be used by others who are providing commercial products that use it, so it can't be that bad.

For me it's a good starting point. I can focus on the FS part of the code. Later if I find bugs in dokan, want more performance, want more control, then I can look at writing the kernal part myself.

Code-o-mat29-Dec-10 11:22

29-Dec-10 11:22

cmk wrote:
The fact that it's open source alleviated any concerns about installing as admin ... or do you mean concerns for deploying to your customers ... yes, I could see that being an issue.

-that's what i meant

About the lingering, it's really nothing serious, it's just an "eccentric" thing of me, i can live with it. Smile | :)

Re: Confusion about virtual files and folders. [modified]

peterchen28-Dec-10 8:53

peterchen

28-Dec-10 8:53

What you are looking for is not an shell extension handler, but a shell namespace extension:

MSDN 1[^]

MSDN 2[^]

CodeProject[^]

It's been years since I looked into this, and at least back then, it was a pain - lots of low level COM handling, lots of unexpected (and unexplained, but probably necessary) behavior on the side of explorer, etc. However, I've seen better samples and utilities that make that easier.

Agh! Reality! My Archnemesis![^]

| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy

Code-o-mat29-Dec-10 0:43