НахлобучРаз уж ты начал про говнокод и скатился к оскорблениям, то я вправе ответить тем же.
Ух какие мы опасные. Ну что ж, вперёд и с песней.

НахлобучВ то время, как я пытаюсь поговорить с тобой только про потоковый ввод-вывод, ты уже успел помянуть про БД, FILESTREAM, SqlFileStream, блобы, респонзы клиентов, аплоад файлов и снятие данных с устройств. И не притворяйся, что ты не понимаешь, что это уход от ответа и подмена предмета. Я всеми силами пытаюсь вернуть тебя к первоначальной теме дискуссии, но ты изо всех сил увиливаешь.
Ты не поверишь, все ужасы, что ты тут с таким напором наперечислял, у меня уместились в одном маленьком посте: 14454086 . Какая тут может быть подмена? Я всеми силами пытаюсь объяснить, что тебя заносит на ровном месте куда-то в обочину. Но ты продолжает писать какую-то жуть. Занятно.

НахлобучВнимание, вопрос по существу: ты осознаешь, что весь код, который ты тут привел -- говно и что либо при любых значительных объемах данных он будет валить систему по OutOfMemoryException либо будет протекать (leak) изо всех сил?
Внимание, ответ по существу.
1. Я не осознаю, что "весь код, который я тут привел -- говно и что либо при любых значительных объемах данных он будет валить систему по OutOfMemoryException либо будет протекать (leak) изо всех сил" .
2. Зато я осознаю, что весь мой код - корректный, отлаженный и стабильный. Замечательно ведет себя на больших нагрузках сервера приложения. Честно создает архивы и их распаковывает. Никакик учетек памяти в нём не было и нет.
3. Так же я осознаю, что твой код, который ты тут писал с обворачиванием прочитанных байт в стрим - безумное студенческое гавно, которое только видывал свет.
4. Так же я осознаю, что первый твой пост с File.ReadAllBytes - бред сивой кобылы. Очень сивой.
5. Такой ответ тебя устроит?

НахлобучВо-первых, когда слышишь от инженера (я надеюсь, ты себя таковым считаешь) словосочетание "файловый оверхед" -- это многое говорит о его квалификации.
Ты просто в очередной раз демонстрируешь своё незнание предметики. "Инженер". Ну это простительно для вчерашних студентов, которые только только выпустились из ВУЗа.
http://en.wikipedia.org/wiki/Overhead Overhead (business), the ongoing operating costs of running a business
Engineering overhead, ancillary design features required by a component of a device
Overhead (computing), ancillary computation required by an algorithm or program
Overhead information, for telecommunication systems
File system overhead, storage or other consideration required by a file system that is not directly related to data.
Any physical object situated, or action occurring above:
Overhead wire, for power transmission
Overhead cable, for signal transmission
Overhead projector, a display system
Overhead cam, a mechanical device
Overhead join, in air traffic control
Overhead (band), a Finnish progressive rock band


НахлобучВо-вторых, твой "рецепт" внутри использует потоки просто потому, что разработчки из Microsoft далеко не дураки и в публичном API предоставили только возможность записи и чтения в поток ( PackagePart.GetStream ).
1. В моём "рецепте" используетя этот метод . К чему твой вброс? Лишь бы что-то пукнуть? Понятно.
2. Для тех, кто забарикадировался в танке, я повторяю: если нужен стрим - используй его (доработать класс), если нужен байтовый массив - используй его (реализация сделана).
3. Но говорить, что весь современный мир использует потоковый ввод вывод - это глупо, безапеляционно и феерично. Только полный идиот может заявлять такое. Согласен?

Нахлобучcooldeveloper23. Признайся, ты начал свой вброс вот этим безумным постом 14452467 про File.ReadAllBytes, не разобравшись в ситуации. Все прекрасно понимают, что File.ReadAllBytes тут вообще ни у кассы, ибо это просто демо пример для инициализации входа массивом байт.Прекрасно, еще одно место, где я должен был о чем-то догадаться.
Ты разучился читать код? Или ты обычно смотришь на первую строчку примера, а потом начинаешь воображать себе реализацию?
Нормальные люди бы прочитали код, осознали его суть и логику и уж потом бы начали комментировать. Но это не твой случай. Ты тупо выдернул из контекста первую строчку File.ReadAllBytes и вбросил какой-то ляп. После того, как я тебе объяснил, что ты сморозил глупость, ты не нашел ничего лучше, как отжечь ещё более каверзный вброс: "Все прогрессивное человечество использует потоковый ввод-вывод"
Это пять!

НахлобучТогда так: как же ты сам не понял, что это был не вброс, а просто иллюстрация ущербности твоего подхода загрузки всех архивируемых данных в память? Это же всем видно, непонятно, как же ты не догадался.
Ты долго будешь дурака включать? Я тебе уже раз 10 объяснил, что в 99.9% случаев нужно именно полностью загружать объект в память - чтение / запись в БД, как вариант. Тему насчет EF продолжать, по которой ты тихло слился в сторонку?

Нахлобучcooldeveloper2Не более того. Потом ты понял, что сел в лужу, и ляпнул вот это 14452881 мол "всё прогрессивное человечество использует потоковый ввод-вывод". Что за бред?Смотри комментарий про "твой код -- говно".
Смотри комментарий про "твой код гавно", "первый комментарий гавно", "ВУЗ твой гавно". Вроде всё четко описал, у тебя не должно возникнуть проблем при чтении.

Нахлобучcooldeveloper24. Человечество идет по легкому пути и использует байтовые массивы, т.к. это удобно и не требует высвобождения памяти. Для более редких случаев, когда требуется читать поток по кускам, возможно применение и стримов.Смотри комментарий про "твой код -- говно". Ты решаешь неимоверно узкую задачу и с жуткой упертостью отстаиваешь неверную позицию, что это -- зе бест.
1. Смотри комментарии про твой код, твой ВУЗ и тебя.
2. С каких это пор работа с байтовыми массивами - "неимоверно" узкая задача? Что за бред ты несешь?
3. Как-раз таки работа с потоками и чанками данных - это "неимоверно" узкая задача. Все нормальные люди пишут и читают объекты в массив байт и живут припеваючи.

НахлобучУй ты лапочка, ну почитай сам уже. Вот тут 14453404 ты говоришь со мной, вот тут 14453594 -- с Изопропилом.
Изопропил точно так же, как ты, учавствует в дискуссии. Ты предлагаешь мне дублировать посты персонально под тебя?

НахлобучПовторяю в последний раз -- я про EF в частности и про ORM в целом с тобой не говорил и не собираюсь.
EF и ORM - это уточнение и, собственно, следствие от первого высказывания про БД и блобы. В любом случае ни в первом ни во втором случая про FILESTREAM не было и речи. Согласен?

Нахлобучcooldeveloper2Ты должен был догадаться о следующем (и догадался, просто в силу своей упертости не желаешь признавать своего просада):
1. Ты в своем гавнокоде сначала считываешь всё в память, а потом массив байт оборачиваешь в стримГовно -- это твой код, милчеловек. Я же в своем коде основывался на том определении класса ZipMemory, что ты предоставил. Не надо теперь хлопать глазками как девочка и рассказывать, что ты совсем не то имел в виду.
1. Говно - это твой иснтитут, который выпускает таких неучей на улицу.
2. Смысл предоставления ZipMemory был в том, чтобы показать, что в его теле фигурирует не массив байт, а поток . Это был ответ на твой гавнокод: 14454334
3. Ты же как мартышка уцепился за несоответствие типов MemoryStream и FileStream и начал верещать как удавленный.
4. Ох и ах. Какой ужас, перепутали типы стримов. Даже если и так, то так или иначе там и не пахло полной загрузкой файлов в память, о которой ты орал во всю глотку.

Нахлобучcooldeveloper22. Я в свое коде показываю, что не нужно ничего предварительно загружать в память, нужно сразу инициализировать стрим с дескриптором на файлУже устал говорить. Дискуссия (срач, точнее) с тобой напоминает игру в шахматы с голубем.
Дискуссия (срач, точнее) с тобой напоминает пинание поросёнка в луже. Отгадай, кто в роли поросенка? Правильно, роли поросенка Нахлобуч.

Нахлобучcooldeveloper24. Я тебе пишу про непринципиальность сего и изменяю в ZipMemory свойство Body на универсальный тип Stream, чтоб успокоить твоё негодованиеХорошая непринципиальность, что уж.
Которая так или иначе показывает, что никакой загрузки файлов в память не будет. В чем ты облажался.

Нахлобучcooldeveloper25. Ты прикидываешься бревном и опять начинаешь грузить меня своими вбросами о косячности кастинга FileStream и MemoryStreamЧто такое "кастинг FileStream и MemoryStream"? Ты инженер или нет? Выражайся технически правильными терминами.
Да, я уже узнал о том, какой ты "инженер". Если для тебя понятие файлового оверхеда в диковинку, что слово "кастинг" вообще расщепит твой сознание. Это слишком сложные термины, не думай о них. Сосредоточься на ответах.

НахлобучСядь, остынь, подумай. Адекватный программист мог хотя бы реализовать в ZipMemory интерфейс IDisposable. Ты же не сделал и этого и снова прикрываешься "догадалками". Взялся писать код -- пиши нормально, а не в своем стиле.
Сижу, остывший, в раздумьях. Адекватному программисту не нужна реализация IDisposable в ZipMemory, т.к. с таким же успехом он может диспоузить Body. Для любителей запаковать логику в единый флакон - я не против, пакуй. Главное, не воняй и не пиши глупости про весь современный мир.

Нахлобучcooldeveloper2Я вообще не должен в реализации со стримами заботиться о том, что и как ты там собираешься диспоузить - я тебе прокидываю стримы, ты с ними работаешь.Снова какая-то фраза от грузчика, а не от программиста.
Если у тебя сложности с пониманием элементарных вещей, могу посоветовать сад.

Нахлобучcooldeveloper21. Ответил тут 14453562
2. В MemoryStream, это очевидно даже из сигнатуры метода.
Ты осознаешь, что у тебя весь архив будет лежать в буфере в памяти?
Садись, двойка. У любого MemoryStream есть резервное хранилище (память). Не знал? Но в отличие от массива байтов - в массиве байтов нельзя добавить и сократить поток. Читай буквари, а не отжигай на форумах.

НахлобучАй, опять ты сел в лужу, пупсик -- опять ресурсы текут, опять все в памяти держишь...
1. Ты читаешь каким местом? Я тебе уже раз 10 повторил, что за диспоуз стримом сам отвечай. Не внял?
2. Что я держу в памяти? Я принимаю дескрипторы, на выхлопе четсно собранный MemoryStream. Акстись?

НахлобучНу да ничего, тебе не впервой. А казалось бы большой мальчик уже. На, мотай на памперс
1. Ты уверен, что твой гавнокод рабочий? Авторитетно заявляю, он нерабочий. Более того, он даже не компилится.
2. Ты считаешь, что введение Func<Stream> нереально улучшит ситуацию? Сходи детвору посмеши в садике.
3. Как же так - адекватный программист мог хотя бы реализовать в ZipMemory интерфейс IDisposable. Где?
4. По сути - убогий код, передранный с моего и немного измененный под своё больное воображение.

hVosttcooldeveloper2Тебе всё правильно говорят, винрар на сервере - плохая практика, это тебе любой сисадмин скажет. Но самое большое зло - это в веб приложении запускать дополнительные процессы. Особенно, если дело касается высоконагруженных серверов приложений. Правильным выходом будет работа с архивом в памяти и только в памяти (массив байт или стрим). Это прописные истыины, о которых даже говорить как-то стыдно.

Я посмотрю, как ты в памяти со своим стримом обеспечишь следующие штуковины:

инкрементальное (+версионное) обновление архива

контроль целостности

непрерывное сжатие групп файлов

высочайший уровень сжатия текстовых данных

электронная цифровая подпись

информация для восстановления

разбитие на тома

... да и многое другое

консольный винрар на столько мощнейшая штука, познать всю мощь которую это целое дао

а то, что ты там не умеешь запущенными процессами в памяти рулить, запускать их в одтельном потоке, скармливать данные, управлять степенью загрузки вычислистельных ресурсов, это только твои личные проблемы

если уж зарекся что-то называть «плохой практикой» будь добр изложить конкретные критичные/нерешаемые проблемы, иначе смысл этого высказывания — лишь пыль, которую пускаешь людям в глаза


Мне эти штуковины не нужны. Нужно просто сжать n файлов в архив. Всё.

1. Ты уверен, что твой гавнокод рабочий? Авторитетно заявляю, он нерабочий. Более того, он даже не компилится.
2. Ты считаешь, что введение Func<Stream> нереально улучшит ситуацию? Сходи детвору посмеши в садике.
3. Как же так - адекватный программист мог хотя бы реализовать в ZipMemory интерфейс IDisposable. Где?
4. По сути - убогий код, передранный с моего и немного измененный под своё больное воображение.
5. С какой такой стати ты принудительно диспоузишь входные потоки, кто дал такое право?
6. Твой код уровня помойки. Рассмешил.