Чтение сжатого файла и запись в новый файл не позволит распаковать

РЕДАКТИРОВАТЬ: по-видимому, мои предложения неверны/недействительны/независимо... пожалуйста, используйте один из других, которые, несомненно, были сильно реорганизованы до такой степени, что невозможно достичь дополнительной производительности (иначе это означало бы, что они такой же недействующий, как и мой)

using (System.IO.StreamReader sr = new System.IO.StreamReader(@"C:\mydata.dat"))
{
    using (System.IO.StreamWriter sw = new System.IO.StreamWriter(@"C:\mynewdata.dat"))
    {
        byte[] bytes = new byte[1024];
        int count = 0;
        while((count = sr.BaseStream.Read(bytes, 0, bytes.Length)) > 0){
            sw.BaseStream.Write(bytes, 0, count);
        }
    }
}

Читать все байты

byte[] bytes = null;
using (System.IO.StreamReader sr = new System.IO.StreamReader(@"C:\mydata.dat"))
{
    bytes = new byte[sr.BaseStream.Length];
    int index = 0;
    int count = 0;
    while((count = sr.BaseStream.Read(bytes, index, 1024)) > 0){
        index += count;
    }
}

Прочитать все байты/записать все байты (из ответа svick):

byte[] bytes = File.ReadAllBytes(@"C:\mydata.dat");
File.WriteAllBytes(@"C:\mynewdata.dat", bytes);

ТЕСТИРОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ С ДРУГИМИ ОТВЕТАМИ:

Только что провел быстрый тест между моим ответом (StreamReader) (первая часть выше, копия файла) и ответом svick (FileStream/MemoryStream) (первый). Тест состоит из 1000 итераций кода, вот результаты 4 тестов (результаты указаны в целых секундах, все фактические результаты немного превышают эти значения):

My Code | svick code
--------------------
9       | 12
9       | 14
8       | 13
8       | 14

Как видите, по крайней мере в моем тесте мой код работал лучше. Одна вещь, которую, возможно, следует отметить в моем случае, это то, что я не читаю поток символов, я фактически обращаюсь к BaseStream, который предоставляет поток байтов. Возможно, ответ Свика медленный, потому что он использует два потока для чтения, а затем два для записи. Конечно, есть много оптимизаций, которые можно было бы сделать, чтобы ответить svick для повышения производительности (и он также предоставил альтернативу для простого копирования файлов)

Тестирование с третьим вариантом (ReadAllBytes/WriteAllBytes)

My Code | svick code | 3rd
----------------------------
8       | 14         | 7
9       | 18         | 9
9       | 17         | 8
9       | 17         | 9

Примечание: в миллисекундах 3-й вариант всегда был лучше

StreamReader предназначен для чтения последовательности символов, а не байтов. То же самое относится и к StremWriter. Поскольку рассматривать сжатые файлы как поток символов бессмысленно, вам следует использовать некоторую реализацию Stream. Если вы хотите получить поток в виде массива байтов, вы можете использовать MemoryStream.

Точная причина, по которой использование потоков символов не работает, заключается в том, что они по умолчанию предполагают кодировку UTF-8. Если какой-то байт не является допустимым UTF-8 (например, второй байт заголовка, 0x8B), он представляется как «символ замены» Unicode (U+FFFD). Когда строка записывается обратно, этот символ кодируется с использованием UTF-8 во что-то совершенно отличное от того, что было в исходном коде.

Например, чтобы прочитать файл из потока, получить его как массив байтов, а затем записать его в другие файлы как поток:

byte[] bytes;
using (var fileStream = new FileStream(@"C:\mydata.dat", FileMode.Open))
using (var memoryStream = new MemoryStream())
{
    fileStream.CopyTo(memoryStream);
    bytes = memoryStream.ToArray();
}

using (var memoryStream = new MemoryStream(bytes))
using (var fileStream = new FileStream(@"C:\mynewdata.dat", FileMode.Create))
{
    memoryStream.CopyTo(fileStream);
}

Метод CopyTo() доступен только в .Net 4, но вы можете написать свой собственный, если используете старые версии.

Конечно, для этого простого примера нет необходимости использовать потоки. Вы можете просто сделать:

byte[] bytes = File.ReadAllBytes(@"C:\mydata.dat");
File.WriteAllBytes(@"C:\mynewdata.dat", bytes);