НахлобучЕсли это задачи уровня домашней работы -- то возможно.
А что, уровень "не домашней" работы - это код только с наличием Stream? Сходи в сад и повесели детишек.

Нахлобучcooldeveloper2CopyTo появился только в WF 4.0, а как же быть FW 3.5 и ниже?Самому написать, очевидно.
Ай, умничка - что и требовалось доказать. Точно так же и здесь, нужен именно Stream в моем классе, берешь и дописываешь реализацию (пара строк кода).

Нахлобучcooldeveloper2Докладываю по существу, SqlFileStream не реализует загрузку данных из потока, разработчики не позаботились. Что и требовалось доказать.Что в твоем понимании "загрузка данных из потока"?
Слушай, тебе и в жизни всё нужно разжевывать и класть в рот? Мы же уже всё обговорили выше и ты, вроде как, понял всё...
Речь о [Файл] => [Stream] => [Load to SqlFileStream] => [БД]

НахлобучЗачем мне твои интовые операции, если я читаю файл с БД и отправляю его в Response клиенту? Или ты предлагаешь дополнительно его обернуть в MemoryStream и отдать через Response.OutputStream? Уволен без выплаты зарплаты.Повторю вопрос: это потоковая опеация или нет? [/quot]
Response.OutputStream - конечно потоковая. Теперь ты мне ответь на вопрос: зачем мне твои интовые операции, если я читаю файл с БД и отправляю его в Response клиенту? Или ты предлагаешь дополнительно его обернуть в MemoryStream и отдать через Response.OutputStream?

НахлобучА я предлагаю в цикле считывать буфер из SqlFileStream и записывать его в OutputStream.
Да ты ж мой хороший - а я предлагаю дописать еще один метод к моему классу, который работает с MemoryStream. Вопросы, пожелания?

Нахлобучcooldeveloper2Если у тебя туго с мозгами, что поясню: байтовые операции - это операции с byte[], потоковые - с Stream. Так лучше? До тебя ни у кого вопросов по этому поводу не возникало.
stream.CopyTo(anotherStream) -- это какая операция?
Потоковая.

НахлобучНачнем с того, что SqlFileStream в принципе появился только в 4.0. Покажи лучше, как он таки научился загружать данные из потока в .NET 4.0+
Опять двойка... Нахлобуч, так недолго и вылететь из школы. Не?
http://msdn.microsoft.com/ru-ru/library/system.data.sqltypes.sqlfilestream.aspx Поддерживается в версиях: 4.5, 4, 3.5 с пакетом обновления 1 (SP1), 3.0 с пакетом обновления 2 (SP2), 2.0 с пакетом обновления 2 (SP2)

Нахлобучcooldeveloper2Садись, двойка. Ты предлагаешь читать файл из базы, создавать отдельный поток и отправлять его в OutputStream? Кхе..кхе.Я писал как я предлагаю. Но могу и повторить -- в цикле считывать буфер из SqlFileStream и записывать его в OutputStream.
Ты смешал мух и котлет. Тут речь о EF и чтении блоба (varbinary(max), к примеру). Чтение напрямую блоба в EF и L2S маппится прямо в массив байт. Имея честный массив байт, нахрена мне еще OutputStream задействовать? Ппц, ты трудный...

Нахлобучcooldeveloper2Зачем мне нужен поток, если я собираюсь писать пакет байт в БД?С точностью до наоборот -- в цикле читаем буфер из InputStream и пишем его в SqlFileStream.
Ужос. Причем тут SqlFileStream? Ты, вообще, понимаешь, о чем речь? Дискутируем о блобе + EF и FILESTREAM, это как бы 2 темы. 1. Я привожу пример, что имея данные в блобе и работая с EF, никакие потоки нафик не нужны.
2. FILESTREAM. Я привожу пример с файлстримом в доказательство того, что методы работы иногда сводятся только к байтовым операциям. В доказательство я привел именно этот класс, разработчики которого забили на методы чтения с потока. Поэтому приходится пилить свои костыли (FW < 4.0)

Ау, ты в космосе, что ли?

НахлобучНивапрос,


Сути дела не меняет -- в памяти по-прежнему будет содержимое каждого файла из c:\windows\system32 плюс сам архив.
Ты с дубу рухнул? Что это за гавнокод? Уволен без выплаты зарплаты!

Так надо:




Нахлобуч, ты меня пугаешь...

Antonariycooldeveloper2пропущено...
Ну а что мне ещё предложить тому, кто читает жопой да ещё и с середины темы? :)Громкое заявление для того, кто жопой пишет
Громкое заявление для читающих ею

Изопропилcooldeveloper2Изопропилушка, алё?

Я всё ещё жду чанкинга для EF.

Поторопись, родненький...

без EF жизни нет?

Не вопрос, возьми классический ADO.NET. Ты блоб читаешь в поток?

cooldeveloper2Изопропилпропущено...


без EF жизни нет?

Не вопрос, возьми классический ADO.NET. Ты блоб читаешь в поток?

Ты конечно можешь сам принудительно читать блоб ридером через SqlDataReader.GetStream, но нафига это нужно? Речь о адаптерах и ридерах, которые вмапливают данные в DataTable. Какой стрим? Зачем?

cooldeveloper2cooldeveloper2пропущено...


Не вопрос, возьми классический ADO.NET. Ты блоб читаешь в поток?

Ты конечно можешь сам принудительно читать блоб ридером через SqlDataReader.GetStream, но нафига это нужно? Речь о адаптерах и ридерах, которые вмапливают данные в DataTable. Какой стрим? Зачем?
Это лишено всякого здравого смысла, т.к. нужно читать сразу в массив байт. Если блоб такой большой, что его напряжно загружать сразу в память, возникает вопрос, какого хрена он, вообще, у тебя в блобе сидит? Ведь по рекомендациям MS в блобах оптимальнее всего хранить файлы до 256Кб. Но даже самый экстремум, это 256Кб - 1Мб, где фрагментация будет более менее приемлема.

Изопропилcooldeveloper2блоб ридером через SqlDataReader.GetStream, но нафига это нужно?
передать поток потребителю имеющему на входе поток.
Пусть потребитель потребляет и массив байт. Не?

Изопропилcooldeveloper2Пусть потребитель потребляет и массив байт. Не?
и так каждый в цепочке?
Генерируешь условия на лету? Цепочки уже появились. Смотри, memory leak не отхвати в своих цепочках со стримами.
Чанкинг будет?

Нахлобучcooldeveloper2[Файл] => [Stream] => [Load to SqlFileStream] => [БД]Ты без стрелочек объясни. Как должна быть реализована операция "загрузить данные из потока"?
Слушай, я уже не знаю, как тебе и что объяснять. Сначала начал человеческим языком, потом стрелочками, теперь уж не знаю как.
1. Ну смотри, есть физический файл.
2. Ты создаешь поток, который ссылается только на его дескриптор (File.OpenRead).
3. Ремарка: надо загнать файл в FILESTREAM (это тип данных такой на сиквел сервере).
4. Реализация SqlFileStream не поддерживает использование FileStream = File.OpenRead напрямую. Да, в FW 4.0 появился у Stream новый метод CopyTo, который унаследовался и в SqlFileStream. Можно для задач с новым FW обойтись тупым CopyTo из FileStream. Но для FW < 4.0 приходится писать свой дополнительный код. О чем и речь. Разрабы не позаботились о том, чтобы пользователи класса напрямую с потока загружали в FILESTREAM сиквела данные. Только с массива байт (Read / Write). Мысль понятна?

НахлобучТы на что отвечаешь?
На твой вопрос.

НахлобучИ как может быть название свойства (Response.OutputStream) операцией?
У тебя проблемы с памятью? Вот тут ты меня спрашивал: 14454595
...Нахлобучcooldeveloper2Зачем мне твои интовые операции, если я читаю файл с БД и отправляю его в Response клиенту?
Повторю вопрос: это потоковая опеация или нет?
Причем тут "название свойства" Response.OutputStream? В вопросе четко говорится об операции "читать" и "отправлять". У меня складывается ощущение, что тебе больше нечего сказать и ты пишешь какую-то муть, лишь бы только всех запутать. Это так? Если это так, то я не вижу смысл дальнейшего обсуждения. Если есть что сказать по делу, с радостью послушаю.

НахлобучЕще раз: приведенный метод -- он реализует потоковую операцию копирования?
Response.OutputStream - это свойство, а не метод. Ты уж определись.

НахлобучПовторяю: предлагаю в цикле считывать буфер из SqlFileStream и записывать его в OutputStream. Ничего ничем оборачивать не надо, оставь свои домыслы при себе.
Код в студию.

Вот вариант SQL FILESTREAM бы без каких-либо циклов и прочей мути. Через родной Read(byte[]).




А потом тупо Response.BinaryWrite. Всё.

НахлобучОк, ошибся с версией фреймворка. И все же -- каким образом SqlFileStream научился загружать данные из потока в .NET 4.0?
Ты же сам ответил на этот вопрос тут: 14454271
Али забыл уже? Напомню, ты правильно ответил: fileStream.CopyTo(sqlFileStream)
Но этот вариант для 4.0 и выше. Для остальных случаев нужно писать педали.

Нахлобучcooldeveloper2Ты смешал мух и котлет. Тут речь о EF и чтении блоба (varbinary(max), к примеру). Чтение напрямую блоба в EF и L2S маппится прямо в массив байт. Имея честный массив байт, нахрена мне еще OutputStream задействовать? Ппц, ты трудный...Я про EF ни разу не упоминал даже.
Я упоминал. И приводил примеры респонза именно для блобов, а не для FILESTREAM. А ты взял и смешал всё в кучу. Не хорошо.

НахлобучЭто не ко мне, повторяю. Я про EF с тобой не говорю. Плюс ты снова не в кассу.
Смотри выше. Если про EF не говоришь, то и не нужно брать мои примеры про Response, которые касаются именно блобов. А то выдрал из контекста и сидишь умничаешь.

НахлобучТо есть ты хочешь сказать, что вот этот код скомпилируется?
Ты понял, что обосрался и решил придраться? Вот так скомпилируется:




НахлобучНет, МСУ, он не скомпилируется. Посему повторяю свое утверждение -- в памяти по-прежнему будет содержимое каждого файла из c:\windows\system32 плюс сам архив.
Нет, Нахлобуч, он скомпилируется. И ты это знаешь. Посему, никакими загрузками в памяти тут и не пахнет.

НахлобучЧего-чего? Что значит "Реализация SqlFileStream не поддерживает использование FileStream = File.OpenRead напрямую"?
Только промежуточное копирование FileStream в SqlFileStream.

НахлобучВ общем, я понял. В терминологии ты не силен, в реальном использовании, судя по всему, тоже.
Всё намного хуже - ты облажался несколько раз и пытаешься соскачить в "терминологию", в "свойство" Response.OutputStream и в прочие не имеющие к делу определения. Забавно.

НахлобучДа пожалуйста, можешь даже в рецепты добавить.
Умничка. А я тебе про что битый час твержу?

Нахлобучcooldeveloper2Я упоминал. И приводил примеры респонза именно для блобов, а не для FILESTREAM. А ты взял и смешал всё в кучу. Не хорошо.Я про EF не упоминал, про него с другими беседуй.
Я ж тебе уже писал, тогда не влазь в этот разговор с "другим о EF. Там речь шла о блобах и респонзе, ты взял и вырвал респонз из контекста и прикрутил ко второй теме про FILESTREAM. Пришлось тебе примеры показывать и для FILESTREAM. Сам всех запутал, а виноваты я и "другой".
Тем не менее, давай поговорим об ORM. Не сцать.
Например, EF и L2S маппят блобы в массив байт. Никаких потоков. Что делать в этом случае? Или разработчики EF и L2S му**ки - должны были тебе выбросить стримовый сосок, через который ты дергал бы блобы? Горю желанием послушать твой высер на эту тему, любитель потоковой обработки данных.

НахлобучЯ про EF не упоминал. Если отвечаешь мне -- от и отвечай на мои вопросы, а не занимайся фигурной резьбой по чужим цитатам.
Ты про EF не упоминал, но вырвал из его контекста спич про респонз. Как понимать?

НахлобучВо какой ты джигит. Молодец. Но напомню -- тут ( 14453716 ) у тебя MemoryStream.
Ты ж мой хороший, неужели ты не понял с ходу, когда я про File.OpenRead написал?




Ведь даже студент бы понял, что речь идет о чистом потоке, без загрузки его в память. Но нет, ты придрался к банальному несоответствию Stream <=> FileStream и начал дальше слюни пускать, мол я не я, жопа не моя. Не стыдно? Ведь все поняли, о чем речь идет. Особенно когда ты жег напалном про:




Это ж просто жесть какая-то...

НахлобучДаже если закрыть глаза на твое изменение условий на лету
Какие такие изменения на лету? Ты о той дурке, которую сам включил?

Нахлобучто опять же -- у тебя останется куча незакрытых потоков и таки архив целиком в памяти. Опять незадача вышла. Что делать будешь? Снова на ходу код править?
Кто-то мешает их диспоузить? Ты хотел работы с потоками - держи:




На входе потоки - на выходе поток. Как ты будешь их освобождать - это твои проблемы. Не хочешь заморачиваться с освобождением ресурсов - кури массив байтов, просто и вкусно. Хочешь более тонкого подхода с потоками - бери стримы, только за memory leak теперь сам следи.

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

НахлобучЗабавно ты постоянно увертываешься от ответа и перескакиваешь с темы на тему. Начал с невразумительного пассажа ( 14452965 ) о "мой велосипед работает только с потоками (через байтовый массив, без файлового оверхеда)." и все заверте...
1. Я увертываюсь от ответа? Ты спятил, я четко отвечаю на твои разрозненные вопросы. То сначала ты искаверкал вопрос по поводу свойства OutputStream, то начал писать про какие-то методы. Соберись и задай вопрос по существу, а то виляешь по сторонам, а толку никакого.
2. По поводу пассажа. Не вижу никаких противоречий, ибо мой лисапед работает только с потоками (реализация), а через байтовый массив (без файлового оверхеда) он предоставляет вход и выход. Ситуация выглядит печально, что тебе об этом еще и нужно писать, т.к. предоставленный код говорит сам за себя.
3. Признайся, ты начал свой вброс вот этим безумным постом 14452467 про File.ReadAllBytes, не разобравшись в ситуации. Все прекрасно понимают, что File.ReadAllBytes тут вообще ни у кассы, ибо это просто демо пример для инициализации входа массивом байт. Не более того. Потом ты понял, что сел в лужу, и ляпнул вот это 14452881 мол "всё прогрессивное человечество использует потоковый ввод-вывод". Что за бред?
4. Человечество идет по легкому пути и использует байтовые массивы, т.к. это удобно и не требует высвобождения памяти. Для более редких случаев, когда требуется читать поток по кускам, возможно применение и стримов.

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

Нахлобучcooldeveloper2Я ж тебе уже писал, тогда не влазь в этот разговор с "другим о EF. Там речь шла о блобах и респонзе, ты взял и вырвал респонз из контекста и прикрутил ко второй теме про FILESTREAM. Пришлось тебе примеры показывать и для FILESTREAM. Сам всех запутал, а виноваты я и "другой".Покажи мне место, где я влез в твой разговор с "другими о EF".
1. Вот тут 14453404 я написал про честный массив байтов при работе с БД.
2. И тут же уточнил про EF 14453594 + написал, что для 99.9% задач (особенно для EF и L2S) требуется обязательно помещать такой объект в массив.
3. А вот тут 14453595 ты процитировал моё сообщение про БД. И дальше перевернул всё с ног на голову.
4. Подчеркиваю, эта тема касается блобов и маппинга на свои классы (в т.ч. через ORM). О FILESTREAM тут речи не идет.

Нахлобучcooldeveloper2Тем не менее, давай поговорим об ORM. Не сцать.С другими об этом говори. И истерик не разводи, держи себя в руках, будь добр.
Я в руках, держусь и здравствую. Таки ответ будет или сдулся?

Нахлобучcooldeveloper2Ты про EF не упоминал, но вырвал из его контекста спич про респонз. Как понимать?Дай ссылку на сообщения, где, что и откуда я вырвал.
Выше.

Нахлобучcooldeveloper2Ты ж мой хороший, неужели ты не понял с ходу, когда я про File.OpenRead написал?О чем еще я тут должен догадаться? Ты дал пример кода, в котором был MemoryStream, а потом на ходу -- "ой, а ты не догадался?" -- переиграл все в Stream и снова в белом. Здорово, чоужтам.
Ты должен был догадаться о следующем (и догадался, просто в силу своей упертости не желаешь признавать своего просада):
1. Ты в своем гавнокоде сначала считываешь всё в память, а потом массив байт оборачиваешь в стрим
2. Я в свое коде показываю, что не нужно ничего предварительно загружать в память, нужно сразу инициализировать стрим с дескриптором на файл
3. Ты прикидываешься бревном и начинаешь вещать о несправедливости мира и о том, что FileStream не коррелирует с MemoryStream
4. Я тебе пишу про непринципиальность сего и изменяю в ZipMemory свойство Body на универсальный тип Stream, чтоб успокоить твоё негодование
5. Ты прикидываешься бревном и опять начинаешь грузить меня своими вбросами о косячности кастинга FileStream и MemoryStream
6. Доколе это будет продолжаться? Зри рационально в зерно, а не ковыряйся в шелухе.

НахлобучА ты клёвый. 14455264 -- вот ровно тут ты сменил MemoryStream на Stream. Или не сменил?
Выше я тебе подробно ответил на эту тему. Можешь продолжать дальше включать дурака, тебе идёт.

Нахлобучcooldeveloper2Кто-то мешает их диспоузить? Ты хотел работы с потоками - держи:О using(memory1.Body) я тоже должен был догадаться? Ты изрыгаешь какие-то невразумительные куски кода, я тебе указываю на проблемные места и ты лихо прикрываешься "нучожтынедогадался". Хороший подход.
А ты забавен. Сначала верещишь о том, что дайте мне стримы. А теперь, оказывается, ты не догадываешься, что их диспоузить надо? Аплодисменты. Я вообще не должен в реализации со стримами заботиться о том, что и как ты там собираешься диспоузить - я тебе прокидываю стримы, ты с ними работаешь.

НахлобучНо я отвлекся.
Как обычно. Ничего удивительного.

НахлобучОтветь, пожалуйста, на следующие вопросы, не увиливай. И отвечай не фонтаном бессвязных слов, а так, чтобы тебя можно было однозначно понять.
Вообще-то, я то и дело отвечаю на твои невразумительные вопросы и не увиливаю. Однозначно и безповоротно.

Нахлобуч* Как быть с большими файлами тут: 14453329 ?
* Где будет сформирован архив вот тут: 14453644 ?
* Реализация Copy отсюда ( 14454271 ) -- потоковая операция?
1. Ответил тут 14453562
2. В MemoryStream, это очевидно даже из сигнатуры метода.
3. Ты повторяешься. Ответил тут 14454749 . На что ты ответил тут 14455016 "Отлично. Запомним это"

Нахлобуч, у тебя проблемы с памятью?

НахлобучИ в качестве факультатива -- оченно хотелось бы посмотреть на два метода, которые ты упомянул тут ( 14453664 ; " Если нужна адаптация под потоковый ввод вывод, класс дополняется еще двумя методами" ). Большие у меня сомнения, что ты понимаешь, как работать с потоками.
Не вопрос, вот первый (главный). Второй по аналогии тебе на домашнее задание. Если осилишь, конечно. Т.к. с таким багажом "знаний" тебе придется не легко...

hVosttИзопропил,

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

ShSergecooldeveloper2пропущено...
А рар - это не винрар? :)
Это бесплатная штука, которая работает из-под коммандной строки.
Это таки винрар. И бесплатная эта штука только для создания архива. Вот тут рецептик валяется: http://codearticles.ru/articles/1106
Но самое зло такого подхода заключается в дополнительном процессе на реквест (для серверных приложений). Жирновато будет. За такие действия на сервере принято расстреливать.