смотря что подразумевается под "делать все самому"...
если имеется ввиду неиспользование CopyFrom, то здесь я тоже не согласен.
ХОТЯ есть некоторые моменты, когда CopyFrom не подходит...

CopyFrom передвинет сам указатель на нужное количество байт.
В этом случае манипуляции с Seek (или оберткой над ним - Position) - потенциальный глюкодром, причем достаточно неявный.

Можно пример "навскидку"? Просто я всегда, когда нужно перекинуть данные из одного TStream в другой, пользуюсь CopyFrom (а его второй параметр :=0 - это вообще песня  ). Только в данном случае, если размер исходного файла =0, то при распаковке это приведет к багу - все последующие файлы ошибочно запишутся в этот. Но это контролируемая штука, один if - и всё в порядке.

Вот когда ты вручную указываешь позицию куда писать - ты можешь точно видеть в коде откуда он пишет.
А когда надеешься на невидимый указатель который "вроде бы должен быть тут" - вот это уже потенциальный глюкодром 


MetalFan, 
подразумевается "выполнять position:=" когда точно нужно быть увереным в какую позицию должен установиться указатель.

Добавлено через 7 минут и 5 секунд
дополню на всякий случай, что опыта на стримах съел прилично, старый кусочек его вывалился в первых постах (который за час обрастает нужными полями в хедере (название файла, атрибуты и тп), прикручивается zlib и если надо шифрование).
Никакого глюкодрома за годА плотного щупанья TFileStream.position я не встречал, зато часто натыкался на свои же грабли когда указатель после Write был не там, где должен быть перед очередной операцией (в основном связано было с модификацией кода, когда подзабывалась структура файла).

В контексте данной задачи это (на мой взгляд) будет выглядеть примерно так:

1. установить указатель в 0.
Loop:
  2. считать длину файла (и при необходимости - имя, атрибуты и т.д.)
  3. запомнить позицию указателя
  4. считать файл из потока
  5. установить указатель на "запомненный"+длина файла
goto Loop (пока не достигнем конца потока).

Если доводить до абсурда - то каждая четная операция(2,4) тоже должна обрамляться запоминанием предыдущего положения указателя и ручным передвиганием его дальше.
Извините, но... "это не наш метод".


Большинство из посетителей форума могут сказать то же самое.

... не будем начинать холивар, тем более что к теме он относится слабо 

Добавлено через 1 минуту и 36 секунд

А именно поэтому Read и Write методы TStream - это функции. Возвращающие реальное количество считанного/записанного.

ребят, ну не устраивайте тут считалки. Ctrl+Click еще никто не отменял. а код CopyFrom не так уж и сложен для понимания. и сразу отпадут все вопросы, при каких входных данных этот злобный CopyFrom какие выходные данные оставит)
если кому что-то непонятно, могу здесь код CopyFrom прокомментировать.

да на здоровье)
единственной проблемой, с которой я столкнулся при использовании метода TStream.CopyFrom, и из-за которой от него пришлось отказаться, это была проблема, связанная с использованием ZLib.TCompressStream, ZLib.TDecompressStream...
в частности при распаковке потока следующим кодом:

ибо TDecompressionStream не умеет делать Seek(0, soFromEnd)... 
т.е. мы не узнаем размер распакованных данных, не распаковав их, или не сохранив из предварительно в том же потоке(к примеру).
тогда вместо CopyFrom пришлось использовать нечто такое:

ну вот как-то так...

Ага, точно, есть такое. Одна из причин, из-за которых и перешел на FastZLib.

а какие еще были причины? хотя это наверное уже злостный оффтоп будет)

Он уже был