.NET (C#) - intercepting file operations?

[Spud1]

I'm trying out some different ideas for how to implement my latest project, and i've started looking into the possibility of intercepting certain file operations and handling them myself, as opposed to letting windows do it - or alternativly block the operation while I do some processing (probably the best option actually).

As an example of what I am trying to achieve, say a user has a networked drive attached, called D:

They want to copy fileA to D: , so they drag and drop it onto the D: icon in explorer.

Usually windows would then copy the file over, and thats it[as far as the user is concerned]. What I want to do is when the user drags the file over and drops it, to be able to intercept that event and present the user with some extra options before continuing. To keep things simple for now, we'll say a confirmation box to make sure they want to copy the file.

Now I know that I can monitor folders etc with the 'fileSystemWatcher', but as far as I know that doesn't let me put a block on the actual operation while I execute my code, or abort the operation itself.

I'll keep looking for a way, but if anyone has any ideas or can point me to a class that can do this I'd be grateful, I know we have a couple of .NET experts on here

Thanks in advance,

Spud/Pete

[edit] I should add that i'd prefer to do this all using .NET libraries or pure c# if possible, rather than having to mess about with COM interop to get it done..but if thats the only way then so be it ;/

[TheAnimus]

basically it depends at what level you want too do this.

Here are two ideas:
1. Driver level hook, in kernel mode, easy in pre-vista windows. In the past this has been used to make a shadow copy, re-cycle bin like if you will. Impossible in .net

Major downside, this has intrinsicly no GUI support.

2. Explorer reporting! Explorer.exe is the shell most people are using to choose too copy the files, so you hook it in here, as far as i'm aware there is no easy API for doing this, but then again i've never looked. However it wouldn't be too hard to find the API thats used internally, and hook it (so called 'EAT' Export Address Table hooking) this way your in a GUI application, and can easily make your own gui.

.net isn't really suiteable enless there is some nice COM api. But the overheads of .net just dont make it seam right to me!

[Spud1]

Thanks for your reply

A KMD level hook was my original plan, and it might still be what I end up doing..and its still possible in vista from what I can tell after having a play with the new driver dev kit- but i'm trying to avoid it if i can.

I'll look into hooking into explorer then Thanks for the idea - you're right that .NET is probably not the *best* way to go about it, especially as using COM means unmanaged code..which as you rightly say makes the overheads pointless, however the majority of the application will benefit hugely from being a .NET app so i'd like to try and keep using it for now. If I do things properly it wouldn't be too bad to have a small module of unmanaged code to deal with the explorer hooking and leave the rest of it as managed .NET.

Thanks for the ideas though, i'll keep researching

[TheAnimus]

COM interop is really easy in .net once you've got over some issues.

Okay, what i'm saying is its easy to do it, to get all those niggling little bugs in that DCOM server that was written 2 years ago by someone who's left the company... Well thats harder!

kernel hooking in vista is hard because of the kernel protection stuff. You might be able to get away with this file system, as rather than doing a int 2e hook, it would actually be a file system filter driver, or what-ever the MS name is, which are document. Either way its not the eayest option, as your taking a user mode action, crossing to kernel, back to user, to .net then window.... not going to be nice.

Once you've loaded your .net code, created your window, its not *that* much slower at going hide/show than un-managed code. So that might be an option i supose.

What is it ur trying to do exactly? Replace the copy dialoge?

[Spud1]

Sort-of. What i'm really trying to do is to

a) do some extra checks before letting the user copy over the file - basically checking that the file is one of a list of formats, and is named correctly.

b) present the user with a window where they are required to enter some more information about the file before it is copied over to the server.

Just to clarify the user would be copying from their windows machine (NTFS only) to their own 'virtual' network drive (which is actually just a folder on the server).

It is possible for me to let the user fill in these details after the transfer has taken place, and to do the checks then too - and 'undo' what the user has done if there is a problem - but this is not ideal (prevention better than cure!) and could lead to some syncronisation issues.

If I were to write my own full-blown application to deal with this, or if I used a different method of tranferring files between client and server I wouldnt have these issues..BUT that defeats the point of the exercise

[Spud1]

A quick update on this - i've been playing with hooking in .NET today (thanks to this article: http://msdn.microsoft.com/msdnmag/is...0/cuttingedge/)

and its not *too* complex to implement it like this...

the other idea I have now is to write an explorer namespace extension, which will give me enough control to be able to do what I want to do Thats tomorrows experiment though..

[TheAnimus]

I was just about to say namespace extension after reading your first post!

When i first had my psion, i thought WOW thats really narly!

I tried to create a virtual "Music" device in C++ in explorer. It leaked buckets and had performance which can only be described as mac os x level. By the time it had searched my music database on my rediculously slow AMD k6 (1!) i had lost all intrest, and the project was junked.

However, that is the best way to do it imo, its got a great user front end (easy to add the clsid too the desktop, network neighbourhood, my computer, the save file dialouge (on the left). Will also work smoothly with vista, and not impact the performance of the others.

Not too mention this should be easy to do in .Net via COM interop!