views:

867

answers:

5

Is there a way to hook into the Windows File Copy API from C#? I'm aware this would require unmanaged code, but a code sample or starter would be helpful. I've already seen the C++ code, but it's all greek.

UPDATE: I apologize, I should have been more clear about my intentions. I wish to actually change the copy feature of Windows to be more rigid (e.g. allow queing, scheduling, handle restarts, pauses, etc.). When I said hook, I meant API hook so that when someone starts a copy I get the sources and destinations and can handle it to my heart's desire. I'm old school and used to hook the Mac OS API a lot to do these things so I assumed that in the C++ WINAPI world there was some type of equiv.

+9  A: 

Update: As others have stated, why not just use System.IO.File.Copy(...)? It calls this same underlying API. As Michael G points out, perhaps you intend to call the the FileCopyEx API that allows you to hook progress-indication callbacks(???) That's really the only reason to P/Invoke file-copy stuff in .NET. Details on how to implement FileCopyEx that can be found here: http://pinvoke.net/default.aspx/kernel32/CopyFileEx.html

Original answer: (which you really shouldn't use...)

Code snippet removed because you really shouldn't use it... If you're hell-bent on making busted-code, you can find out how to use it at: Found at http://pinvoke.net/default.aspx/kernel32/CopyFile.html

Yoopergeek
i wouldnt say -1 but its technically the same thing as calling managed code with out the advantages of managed code and the user did ask for unmanaged code
RC1140
The question was: How to hook the Windows API file-copy. Not reasons to use System.IO.File.Copy. Comments on the question should point out System.IO.File.Copy uses the same API, not a down-vote. Thanks bub. Also, like Michael G mentions in his answer - directly calling the API allows you to hook into the progress-event/callbacks.
Yoopergeek
I guess I just get tired of seeing code haphazardly use P/Invoke or reimplementation of BCL code "for performance reasons" because the coder didn't realize or check the provided APIs were already fast. If you preface your post with a note that the only time you should need to P/Invoke for a file copy is to `FileCopyEx` for specific additional information not provided by the managed API, I'll take take back the -1. Otherwise, take it as I'm just a grumpy coder. ;)
280Z28
Z28, I hear ya. I've heavily modified my answer to point out what you just said. :)
Yoopergeek
BTW, I took back the -1 vote. My remaining comment explains my strong leaning towards the managed API wherever possible. :)
280Z28
+1  A: 

You can do so by calling System.IO.File.Copy. Its internal implementation already uses the Windows API.

Edit: File.Copy also handles permissions correctly and has the benefit of throwing an exception with meaningful data if something fails, so you don't have to manually check and analyze the return status.

280Z28
+2  A: 

The other benefit of using unmanaged Copy File API is the ability to have a progress callback.

You can see an example of how to do so here.

Note: as stated in other answers, I would use the managed version of File.Copy as it's safer, and can usually do everything you require.

Michael G
+4  A: 

I wish to actually change the copy feature of Windows to be more rigid

You shouldn't do that in managed code, because of the same reasons you should not write managed shell extensions.

peterchen
That's a good point I hadn't considered. I can't wait until WIN32 gets it's own WOW virtual machine and the CLR is the defacto core API. Until then I'll just have to do this in C++. Thanks.
Nissan Fan