Example:
If you stream your copying, i.e. read a buffer, write a buffer, read a buffer, write a buffer etc until you've run out of data, it will only take as much memory as the buffer size. I expect File.Copy to do this (in the native Windows code, admittedly).
If you want to do it yourself, use something like this:
public void CopyData(Stream input, Stream output)
{
byte[] buffer = new byte[32 * 1024];
int read;
while ((read = input.Read(buffer, 0, buffer.Length)) > 0)
{
output.Write(buffer, 0, read);
}
}
This will only take 32K however big the stream is.
EDIT: As noted in the comments, the streams may well have their own buffers as well, but the point is that you could still transfer a very large file without running out of memory.
If you call something like ReadToEnd() then yes, the contents of the file will be loaded into memory. You're correct in guessing that using a buffer is the appropriate approach to ensure that only a subset of the file's data is loaded into memory at any given time.
No, the whole file won't be loaded into memory.
The memory footprint will depend on the size of buffers you use for reading and writing, and any internal buffers maintained by the stream.
The FileStream class uses an internal buffer whose size can be specified in a constructor overload and which defaults to 0x1000 bytes (probably implementation dependent - this value was obtained by examining the FileStream class using Lutz Reflector).
It really depends on your methodology. If you are using the stream a temporary endpoint, ala ReadToEnd(), you can load the entire file in memory. If, instead, you are buffering, you will not use more than a bit of overhead over the buffer size.