Copy files in c#

87e614b8b888bb2c4485c1ac16d8c779
0
moe 101 Nov 26, 2008 at 20:33

Hi all

I would like to write a little backup application in c#. However, there are many ways to copy files. Now I am wondering which way is the best to go. What would you recommand for copying arbitrary files (any mimetype) with arbitrary size (very small to very big files)?

Should I just use:

File.Copy(pathSource, pathDestination);

or rather stream the files and copy/save the stream?

or more like:

Process proc = new Process();
proc.StartInfo.UseShellExecute = true;
proc.StartInfo.FileName = @"C:\WINDOWS\system32\xcopy.exe";
proc.StartInfo.Arguments = @"C:\source C:\destination /E /I";
proc.Start();

Maybe use robocopy instead of xcopy?

I would also like it to be usefull when copying to a server (“normal” access like a maped network drive, not with FTP).

So… what’s the way to go?

As always any input is greatly appreciated. Thx.

10 Replies

Please log in or register to post a reply.

8676d29610e6c98d6dd2d9c38528cd9c
0
alphadog 101 Nov 26, 2008 at 21:24

First, this may not be the best forum. Surely a C# forum somewhere…

Anyways, are you trying to copy one file, or multiple files at once? File.Copy() is pretty much it, but is limited. You’ll have to roll your own to get fancier. Or, just Google it…

Ex:

http://www.codeproject.com/KB/files/copydirectoriesrecursive.aspx

http://channel9.msdn.com/forums/TechOff/257490-How-Copy-directories-in-C/

87e614b8b888bb2c4485c1ac16d8c779
0
moe 101 Nov 27, 2008 at 00:43

My point was, whether File.Copy() internally handels copying a file the same way as e.g. streaming the file and save the stream. I could not find any info about this using google. I know how to copy a file. But I can not find any info on the internal workings of File.Copy(). E.g. Is there a limit to the file-size you can copy with it?

Schurely there are differences since there are different ways to do it. I am just trying to find the most fitting/reliable way for my case.

I figured “Programming&Development -> languages” sounded like a good place. Sorry if you feel offended. I can try asking elsewhere. Anyway, thx for the response.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Nov 27, 2008 at 07:43

The internal workings of File.Copy() are likely that it calls the OS to do the copy. Which in turn calls upon the motherboard and/or disk drive control logic to move the actual bytes. It’s not necessary for the CPU to touch every byte to copy a file (indeed, it’s very inefficient to copy that way).

As for copying many files, I’m unsure. File.Copy is synchronous, meaning that it will wait for the file to be finished copying before it returns. If there was an asynchronous copy routine, you could send off requests for all the copies and let the OS / disk driver sort them out, and they will probably do something reasonably intelligent as regards scheduling the copies to minimize seek time. This is a case where shelling out to one of those copy commands might be handy, if it lets you easily schedule multiple copies at once.

87e614b8b888bb2c4485c1ac16d8c779
0
moe 101 Nov 27, 2008 at 22:23

I see what you mean. Thx for the info.

6aa952514ff4e5439df1e9e6d337b864
0
roel 101 Nov 29, 2008 at 22:29

I’d go for File.Copy if it can do what you want to do. The actual implementation might depend on the OS, and so its performance. If you want your app to run on a variety of (future) systems/OSes, it is way better than the shell stuff.

87e614b8b888bb2c4485c1ac16d8c779
0
moe 101 Nov 29, 2008 at 23:14

run on a variety of (future) systems/OSes

Interesting thought. But I am only concerned about my own. So, XP and Vista is enough.

Meanwhile I implemented the “shell stuff” with robocopy. As well as a method with CopyFileEx. This way I get some stats about the current copy process. CopyFileEx is however somewhat wired. Sometimes it is incredible fast and sometimes it just “hangs around” for a while. Even in the exact same situation (repeating the same action). I take from it that it indeed uses the OS for the actual copying and that vista sometimes is busy elsewhere (Not that I would be doing anything else… :D) Maybe I try a streaming method later. Then I can compare anyway or use a different method if one fails to do the job. I was mainly wondering if there is a “best” way for my situation since I could not find anything about the internal workings of neither File.Copy() nor robocopy.

Thx for your reply.

8676d29610e6c98d6dd2d9c38528cd9c
0
alphadog 101 Dec 03, 2008 at 18:02

@Reedbeta

As for copying many files, I’m unsure. File.Copy is synchronous, meaning that it will wait for the file to be finished copying before it returns. If there was an asynchronous copy routine, you could send off requests for all the copies and let the OS / disk driver sort them out

http://msdn.microsoft.com/en-us/library/kztecsys.aspx
@moe

My point was, whether File.Copy() internally handels copying a file the same way as e.g. streaming the file and save the stream.

Sorry, your actual question wasn’t clear to me.

That function is probably a (limited) NET wrapper for some deeper Win32 API call; probably something like SHFileOperation or maybe CopyFileEx. Only Microsoft knows the full implementation, so good luck googling! :(
@moe

Schurely there are differences since there are different ways to do it. I am just trying to find the most fitting/reliable way for my case.

Well, there are many reasons for differences between API calls that do the same thing generally. Some calls may focus on simple cases, keeping the call line lean, others may focus on concurrency/threading, or one rich callbacks, etc.

In this case, as Reedbeta suggests, the biggest problems with File.Copy are: synchronous (can’t abort in mid-copy), file-only (copies files one-by-one) and no callbacks (although a FileSystemWatcher would help).

You could write your own Stream solution, but it would be somewhat slower than File.Copy(), but you could build in your own threading and callbacks. Or, you could write your own wrapper for those lower function, or find one out there.
@moe

I figured “Programming&Development -> languages” sounded like a good place. Sorry if you feel offended. I can try asking elsewhere. Anyway, thx for the response.

No offense. I was trying to help, not criticize. This forum is for game programming with no specific language focus. As such, you are talking to a crowd that will contain some C# programmers, and many other types. Finding a C# “specialist” forum may help you get a better response faster.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Dec 03, 2008 at 18:27

@alphadog

http://msdn.microsoft.com/en-us/library/kztecsys.aspx

I know about asynchronous reading and writing, but I don’t see anything there about asynchronous copying. (Of course you could read the file into memory and spit it back out again but as mentioned before I suspect that’s not a very efficient way to copy.)

8676d29610e6c98d6dd2d9c38528cd9c
0
alphadog 101 Dec 03, 2008 at 20:08

My link was meant as supplemental reading to your point, not as a solution to your wondering if there was an asynchronous copy method in .NET (which there isn’t).

As to your second parenthetical point, you are correct. Using FileStream will not let you take advantage of DMA. It will be slower than a wrapper over CopyFileEx(). And, lord knows the Intertubes must be full of codes from h4xorz for this. Here’s one Google spit out:

http://msdn.microsoft.com/en-us/magazine/cc163851.aspx

87e614b8b888bb2c4485c1ac16d8c779
0
moe 101 Dec 05, 2008 at 22:01

This forum is for game programming with no specific language focus. As such, you are talking to a crowd that will contain some C# programmers, and many other types. Finding a C# “specialist” forum may help you get a better response faster.

I see, we just went off on the wrong foot (no offence taken and none intended). I mainly mentioned c# because that is what I am currently using and there might have been some special way in c# I don’t know of. The question itself was more into a general direction on whats a good way to copy. But you are right, I did not formulate the question very well and a c# forum might indeed have been a better choice. It’s just that here are the most helpfull and knowledgeable people I know of. So, I just gave it a try without too many thoughts.

However, Thanks for your input.