We're using your Callback FS Driver for both 32 and 64 bits with C# 2.0.

It's working smoothly on Windows XP and 2003, however we're running into some issues when we install the driver then try to mount the drive and (simultaneously) the user is trying to open My Computer.

Most of the time it freezes the Explorer Window and then doesn't creates the volume correctly making it unusable.
Then when we close our program and execute UnmountMedia with the force parameter set to true, it doesn't removes it from system, only at next reboot.

What I'm looking for is some insight on the (driver installation / volume mount / mounting point) creation process and its interaction with the initialization CbFs callbacks (like CbFsMount, CbFsOpenVolume and CbFsGetVolumeSize).
Also, what timeouts and force options are better, if that is the case.

Fernando Nunes wrote:
It's working smoothly on Windows XP and 2003, however we're running into some issues when we install the driver then try to mount the drive and (simultaneously) the user is trying to open My Computer.

Most of the time it freezes the Explorer Window and then doesn't creates the volume correctly making it unusable. Then when we close our program and execute UnmountMedia with the force parameter set to true, it doesn't removes it from system, only at next reboot.

Unfortunately we can't reproduce this problem. Could you specify in details how to reproduce it?

Quote

Fernando Nunes wrote:
What I'm looking for is some insight on the (driver installation / volume mount / mounting point) creation process and its interaction with the initialization CbFs callbacks (like CbFsMount, CbFsOpenVolume and CbFsGetVolumeSize). Also, what timeouts and force options are better, if that is the case.

The internal mechanism of CallbackFS is quite similar to other standard file systems (FATFS, NTFS). It "simply" passes file system specific requests (that are sent by operating system to the CallbackFS file system driver) to the user mode callbacks. You can find information about these requests and how Windows file systems work in Microsoft's DDK.
Timeouts values are specific to a file system which is implemented by the use of the CallbackFS product. For example the file system can use long-term network operations, so by setting appropriate timeouts you can prevent your storages from freezing.

I'm having this problem specially after a fresh driver installation.
Well.. to reproduce the problem try doing something like:

1) Install the driver. Imediatly after success, invoke another program that does:
CreateStorage, MountMedia, AddMountingPoint
On the CbFsGetVolumeSize and CbFsOpenFile make them invoke a webservice, if possible !

There's a limited set of operations that are allowed in callbacks. Doing many things can cause a deadlock. So you must be *very* careful about what you are doing in callbacks. Ideally, in callbacks you should only read/write local information from/to memory, leaving network and disk operations for other thread, which works in background.

I don't mean to jump into your conversation here, but there was something you said that I hadn't heard before which is of great material importance to Callback FS development in general, and I wondered if you might expound further on it. I posted here because I thought it would be of general benefit to the entire community, but if you would like to take it to a private support ticket that is fine too.

Quote

Doing many things can cause a deadlock. So you must be *very* careful about what you are doing in callbacks. Ideally, in callbacks you should only read/write local information from/to memory, leaving network and disk operations for other thread, which works in background.

I'd like to know about a couple things:

1) Since Callback FS by default is synchronizing callbacks on a specific file, I'd like to know some of the use cases (if there are many) that can cause a deadlock. Can you give a few examples?

2) What is the essential problem with doing network and disk operations in callbacks? The potential problem that I see arising from sending disk operations to another thread is that the callback will complete, leaving the caller expecting that the operation has been completed, and the caller may invoke another callback as a result, but meanwhile, the secondary thread which the first disk operation has been handed to hasn't yet completed. I'm curious as to the exact nature of the problem with a disk operation in a callback, because the nature of the callbacks themselves suggest a completion of one callback before the execution of another.

brado77 wrote:
1) Since Callback FS by default is synchronizing callbacks on a specific file, I'd like to know some of the use cases (if there are many) that can cause a deadlock. Can you give a few examples?

Some badly written file system filter-based application (antivirus, audit tool etc.) can cause the deadlock if it accesses the disks as a consequence of your callback operation. We came across AVG antivirus (some older version) which did this and we had to add a workaround for that particular class of bugs. But who knows, how many other applications have similar bugs.

Next, Windows GUI must not be used from callbacks as this is a straight way to the deadlock.

Network operations are usually safe, but if the OP talks about web services, there's likely some framework to be involved, and who knows what this framework does.

In general, everything depends on the usage scenario. The approach that will work in one application can fail in another application due to seemingly minor difference.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.