struct FileInfo
{
int count;
char ext[5];
};
FileInfo.count = 5;
strcpy(FileInfo.ext, "bla-bla");
fwrite(&FileInfo, sizeof(FileInfo));
Деление файлов
Делаю простой разделитель и склеиватель файлов для винды и стоклнулся с некоторой проблемой. Алнгоритм таков: при делении файлов я открываю через fopen файл с режимом rb, записываю по частям в output-файлы в режиме wb с расширением *.fjsX, где X - номер части. Проблема такая: куда записывать данные о:
1. Количестве частей(чтобы потом их искать и склеивать при склейке)?
2. Исходном расширении файла?
Если вторую проблему еще можно решить простым добавлением, например, к исходному файлу exe расширения jfs, чтобы в итоге выглядело file.exe.jfs0 и т.д., а с первой как - не знаю. Есть идея в том же режиме wb в конце первой части выходного файла подписать количество частей, но не знаю, возможно ли это, и как потом считать их оттуда.. Прошу помощи.
1. Количестве частей(чтобы потом их искать и склеивать при склейке)?
2. Исходном расширении файла?
Если вторую проблему еще можно решить простым добавлением, например, к исходному файлу exe расширения jfs, чтобы в итоге выглядело file.exe.jfs0 и т.д., а с первой как - не знаю. Есть идея в том же режиме wb в конце первой части выходного файла подписать количество частей, но не знаю, возможно ли это, и как потом считать их оттуда.. Прошу помощи.
Цитата: motorw
Делаю простой разделитель и склеиватель файлов для винды и стоклнулся с некоторой проблемой. Алнгоритм таков: при делении файлов я открываю через fopen файл с режимом rb, записываю по частям в output-файлы в режиме wb с расширением *.fjsX, где X - номер части. Проблема такая: куда записывать данные о:
1. Количестве частей(чтобы потом их искать и склеивать при склейке)?
2. Исходном расширении файла?
Если вторую проблему еще можно решить простым добавлением, например, к исходному файлу exe расширения jfs, чтобы в итоге выглядело file.exe.jfs0 и т.д., а с первой как - не знаю. Есть идея в том же режиме wb в конце первой части выходного файла подписать количество частей, но не знаю, возможно ли это, и как потом считать их оттуда.. Прошу помощи.
1. Количестве частей(чтобы потом их искать и склеивать при склейке)?
2. Исходном расширении файла?
Если вторую проблему еще можно решить простым добавлением, например, к исходному файлу exe расширения jfs, чтобы в итоге выглядело file.exe.jfs0 и т.д., а с первой как - не знаю. Есть идея в том же режиме wb в конце первой части выходного файла подписать количество частей, но не знаю, возможно ли это, и как потом считать их оттуда.. Прошу помощи.
В конец 1-го файла, выделить там несколько байт и с их учетом определять его размер.
Цитата: oxotnik333
В конец 1-го файла, выделить там несколько байт и с их учетом определять его размер.
Т.е. количество дополнительных байт в первом файле(части) == количество частей?
Цитата: motorw
Т.е. количество дополнительных байт в первом файле(части) == количество частей?
нет структуру в бинарном режиме туда дописываешь, типа:
Код:
Ух ты.. Вот не додумался точно бы без тебя! Спасибо! :)
P.S. Читаю твои посты на форуме и смотрю - ты мегамозг :)
P.S. Читаю твои посты на форуме и смотрю - ты мегамозг :)
Банально, но еще можно уложить рядышком INI или XML файлик с метаданными.
Наверное, прозвучит пошло, но "bla-bla" не влезет :)
Цитата: hardcase
Банально, но еще можно уложить рядышком INI или XML файлик с метаданными.
Думал над этим, но все "аналоги" как-то же работают без них. Да и тащить его с собой еще все время.. Да и подвержен редактированию он.
Цитата: motorw
Думал над этим, но все "аналоги" как-то же работают без них. Да и тащить его с собой еще все время.. Да и подвержен редактированию он.
Очевидное следствие - "вклеить" его в начало или хвост первого файла, о чем и поведал УК Оксотник.
Структуру проще сделать. Очевидное следуствие - "вклеить" структуру :)
Кстати, банальное решение с файликом, в котором метаданные лежат, можно немного извратить. Назвать его *.fjs0 Пусть следующие велосипедостроители думают, что мы без него обошлись :)
Структуру удобнее в начало вписать. Тогда проще ввести функцию переменного размера тома. Ну и #pragma pack(1) пригодится, возможно.
Структуру удобнее в начало вписать. Тогда проще ввести функцию переменного размера тома. Ну и #pragma pack(1) пригодится, возможно.
Цитата: Kogrom
Наверное, прозвучит пошло, но "bla-bla" не влезет :)
я когда писал, подумал об этом, но ничего другого на ум не пришло, посему оставил это в первозданном виде... домашнее задание т.с.
у меня вопрос к ТС: а почему нельзя при склеивании просто брать по порядку файлы с расширениями "fjs0" "fjs1" ... пока не дойдём до последнего? в этом случае метаданные вообще не нужны
Цитата: LM(AL/M)
у меня вопрос к ТС: а почему нельзя при склеивании просто брать по порядку файлы с расширениями "fjs0" "fjs1" ... пока не дойдём до последнего? в этом случае метаданные вообще не нужны
для пущей уверенности, что ничего не потеряли. лучше вообще в каждую часть дописывать некий хеш исходного файла, а после слияния проверять.
И зачем вообще надо знать о количестве частей?
Что мешает записывать (в начало каждого файла) структуру в которой хранить имя следующей части и исходное расширение. Если имени нет - это последняя часть. Можно так же хранить MD5-хеш файла - это куда более полезная информация, чем нафик никому не здавшееся количество частей.
LM(AL/M)
в принципе можно и так - но как быть если последующие части отсутсвуют? - При такой схеме мы о этом никогда не узнаем.
Идея записывать подобную информацию в конец файла - это хороший способ создать себе (и пользователю) неизмеримые проблемы.
Что мешает записывать (в начало каждого файла) структуру в которой хранить имя следующей части и исходное расширение. Если имени нет - это последняя часть. Можно так же хранить MD5-хеш файла - это куда более полезная информация, чем нафик никому не здавшееся количество частей.
LM(AL/M)
в принципе можно и так - но как быть если последующие части отсутсвуют? - При такой схеме мы о этом никогда не узнаем.
Идея записывать подобную информацию в конец файла - это хороший способ создать себе (и пользователю) неизмеримые проблемы.
Цитата: kot_
И зачем вообще надо знать о количестве частей?
Что мешает записывать (в начало каждого файла) структуру в которой хранить имя следующей части и исходное расширение. Если имени нет - это последняя часть. Можно так же хранить MD5-хеш файла - это куда более полезная информация, чем нафик никому не здавшееся количество частей.
LM(AL/M)
в принципе можно и так - но как быть если последующие части отсутсвуют? - При такой схеме мы о этом никогда не узнаем.
Идея записывать подобную информацию в конец файла - это хороший способ создать себе (и пользователю) неизмеримые проблемы.
Что мешает записывать (в начало каждого файла) структуру в которой хранить имя следующей части и исходное расширение. Если имени нет - это последняя часть. Можно так же хранить MD5-хеш файла - это куда более полезная информация, чем нафик никому не здавшееся количество частей.
LM(AL/M)
в принципе можно и так - но как быть если последующие части отсутсвуют? - При такой схеме мы о этом никогда не узнаем.
Идея записывать подобную информацию в конец файла - это хороший способ создать себе (и пользователю) неизмеримые проблемы.
чем будет хеш сам по себе полезен для восстановления информации?
а при условии того что в первой части имеем всю инфу, то если исходный файл большой, можно будет распарсив только первую часть сказать однозначно, хватает ли оставшихся частей для слияния, что повысит скорость работы.
Цитата: oxotnik333
чем будет хеш сам по себе полезен для восстановления информации?
тем, что мд-хеш как правило хранят отдельно для контроля.
Цитата: oxotnik333
а при условии того что в первой части имеем всю инфу, то если исходный файл большой, можно будет распарсив только первую часть сказать однозначно, хватает ли оставшихся частей для слияния, что повысит скорость работы.
вот когда говорят о "болезни преждевременной оптимизации" - имеют ввиду именно это. Ну распарсиш ты. Ну и что? пусть все 20 частей большого файла получены - но битые. А ты с них (самое главное быстро) соберешь исходный и будешь удивляться своей гениальности.
Цитата: kot_
тем, что мд-хеш как правило хранят отдельно для контроля.
вот когда говорят о "болезни преждевременной оптимизации" - имеют ввиду именно это. Ну распарсиш ты. Ну и что? пусть все 20 частей большого файла получены - но битые. А ты с них (самое главное быстро) соберешь исходный и будешь удивляться своей гениальности.
вот когда говорят о "болезни преждевременной оптимизации" - имеют ввиду именно это. Ну распарсиш ты. Ну и что? пусть все 20 частей большого файла получены - но битые. А ты с них (самое главное быстро) соберешь исходный и будешь удивляться своей гениальности.
А я соберу, схеширую, сравню с исходным и определюсь битые или не битые. А по твоему алгоритму - собираем, собираем... собираем... час прошел, еще один, и бац - неудача, чего то не хватат. (хотя можно парсить исключительно заголовки частей). А если битые части в твоем алгоритме?
К стати, а вчем принципиальность куда помещать структуру об информации, в начало или в конец?
-->oxotnik333
для пущей уверенности что ничего не потеряли достаточно генерировать имена файлов (или расширения) в формате "№ куска-количество"
-->kot_
по поводу хранения в самом файле ссылки на следующий могу вот что сказать: в этом случае получается вместо одной задачи (генерация имён файлов) решаем две: генерация имён + обеспечение связности
для пущей уверенности что ничего не потеряли достаточно генерировать имена файлов (или расширения) в формате "№ куска-количество"
-->kot_
по поводу хранения в самом файле ссылки на следующий могу вот что сказать: в этом случае получается вместо одной задачи (генерация имён файлов) решаем две: генерация имён + обеспечение связности
Цитата: oxotnik333
А я соберу, схеширую, сравню с исходным и определюсь битые или не битые. А по твоему алгоритму - собираем, собираем... собираем... час прошел, еще один, и бац - неудача, чего то не хватат. (хотя можно парсить исключительно заголовки частей). А если битые части в твоем алгоритме?
К стати, а вчем принципиальность куда помещать структуру об информации, в начало или в конец?
К стати, а вчем принципиальность куда помещать структуру об информации, в начало или в конец?
хм. мне казалось что это очевидно.
Если начало файла не содержит твоего заголовка - то тебе и обрабатывать нечего. Либо файл не твой, либо что то еще - но в целом это не важно, ты с ним работать не можешь - о чем пользователю и говоришь.
Если содержит - то проверяешь хеш (считаешь контрольную сумму, вычисляешь фазы Луны - нужное подчеркнуть) т.е. любым приемлимым способом проверяешь полноту информации и обрабатываешь - до тех пор, пока не конец файла.
Твой вариант - идти в конец файла (ХА!!! и этот человек рассказывает тут про скорость) - куда? До конца файла? а потом вернуться на размер структуры и пытаться ее прочесть? Или читать файл до тех пор пока не встретится маркер? Который еще и придумать надо? А если не встретится? Файл битый? А может нам в него вообще лезть не надо? Как понять? Но файл то мы уже прокрутили - как бы там не было, но из конца в конец мы файл УЖЕ прошли - дальше еще надо объяснять?
Из той же оперы - "я беру схеширую..." - схешируешь, милый, схешируешь. Только словообразование тут не от слова "хеш" будет, но тоже из трех букв и с "х" начинается. Потому что, тебе опять же надо все(!) файлы прочесть а потом приступить к их обработке. Либо хешировать и обрабатывать сразу. Но выиграша для тебя тут не будет - что так, что так - файл надо будет поднимать, собираем, собирем - "тут бац, вторая смена"(с). Что так, что так - считал файл - посчитал - сравнил хеш. Вероятен псевдо-выигрыш за счет того, что у тебя не будет компоненты записи, в случае если какой то файл битый - ну так не факт, что это оптимально - в моем случае, пользователю надо будет просто заменить битый файл и операция пойдет дальше - либо мы этот фрагмент пишем как есть, либо пропускаем - в конце концов это может быть вполне допустимо. Можно в конце концов и сразу просканировать все файлы на целостность, либо оставить выбор за пользователем.
Но в твоем решении есть весьма узкое место - если первый файл отсутствует - то у тебя не будет никакой информации о том, чего есть, а чего нет. И это будет наиболее не оптимальным в твоем решении.
Цитата: LM(AL/M)
-->oxotnik333
для пущей уверенности что ничего не потеряли достаточно генерировать имена файлов (или расширения) в формате "№ куска-количество"
для пущей уверенности что ничего не потеряли достаточно генерировать имена файлов (или расширения) в формате "№ куска-количество"
а я не хочу "№ куска-количество". Я хочу что бы было "Пакет1..10"? Я хочу дать каждому фрагменту произвольное имя? Почему нет?
Цитата: LM(AL/M)
-->kot_
по поводу хранения в самом файле ссылки на следующий могу вот что сказать: в этом случае получается вместо одной задачи (генерация имён файлов) решаем две: генерация имён + обеспечение связности
Да, ну и что? Для этого алгоритм разбиения должен быть двупроходным - вначале заполняется список структур - а затем уже выполняется разбиение.
Понятно, что это усложняет алгоритм - и в частности алгоритм сборки - но с другой стороны гарантирует ее качество.
Цитата: kot_
Я хочу дать каждому фрагменту произвольное имя? Почему нет?
а смысл?..
да и вобще не понятно что значит "произвольное имя", генерировать рандомно что ли? (и снова дополнительный код писать для этого?)
а чем "пакет1..10" принципиально отличается от "№куска-количество"?
Цитата: kot_
Понятно, что это усложняет алгоритм - и в частности алгоритм сборки - но с другой стороны гарантирует ее качество.
каким образом?
Цитата: LM(AL/M)
а смысл?..
да и вобще не понятно что значит "произвольное имя", генерировать рандомно что ли? (и снова дополнительный код писать для этого?)
а чем "пакет1..10" принципиально отличается от "№куска-количество"?
да и вобще не понятно что значит "произвольное имя", генерировать рандомно что ли? (и снова дополнительный код писать для этого?)
а чем "пакет1..10" принципиально отличается от "№куска-количество"?
затем, ИМХО, что ты не рассматриваешь саму задачу - ты услышал "порезать файлы" - а дальше начинаешь генерировать "индийский код" не пытаясь понять, в чем состоит задача, поставленная перед тобой.
У пользователя обязательно должна быть возможность управлять выводом имени файла. И опираться на какие либо закономерности программист не может.
Почему? Потому что - "порезать" файл - нужно не просто порезать, а разместить на носителях для передачи (либо для хранения). А если предполагается возможность хранения - необходимо дать пользователю возможность назвать фрагмент файла так, что бы через год-два не гадать - что содержит файл с именем "#23from100". Имя файла - это информация для пользователя и ОС, и разработчику туда лезть незачем. Тем более, что это накладывает весьма существенные ограничения на работу и алгоритм программы. Понятно, что это ИМХО.
Цитата: LM(AL/M)
каким образом?
гарантируя, что в случае потерь информации пользователь будет уведомлен о этом.
ИМХО, я бы решал эту задачу добавлением к каждой части следующего заголовка(что является расширением предложения oxotnik333):
[SourceFileHash] - для проверки, что все части действительно принадлежат одному файлу.
[PartNumber] - собственно для склеивания.
[EndFlag] - дабы знать, что это последняя часть и склеивание можно прекращать.
[CRC] - для контроля целостности данных.
а имена частям давать как "[имя исходного файла]_часть[номер части].[некое наше расширение]".
Код:
[SourceFileHash]
[PartNumber]
[EndFlag]
[CRC]
[PartNumber]
[EndFlag]
[CRC]
[SourceFileHash] - для проверки, что все части действительно принадлежат одному файлу.
[PartNumber] - собственно для склеивания.
[EndFlag] - дабы знать, что это последняя часть и склеивание можно прекращать.
[CRC] - для контроля целостности данных.
а имена частям давать как "[имя исходного файла]_часть[номер части].[некое наше расширение]".
Без точного ТЗ мудрить и додумывать "Что хотел сказать автор", и насколько криворукий будет пользователь, бессмысленно. Можно накидать еще пару десятков вариантов, каждый и которых будет гарантировать целостность и правильность данных, но нужно ли это автору?
Цитата: kot_
затем, ИМХО, что ты не рассматриваешь саму задачу - ты услышал "порезать файлы" - а дальше начинаешь генерировать "индийский код" не пытаясь понять, в чем состоит задача, поставленная перед тобой.
У пользователя обязательно должна быть возможность управлять выводом имени файла. И опираться на какие либо закономерности программист не может.
Почему? Потому что - "порезать" файл - нужно не просто порезать, а разместить на носителях для передачи (либо для хранения). А если предполагается возможность хранения - необходимо дать пользователю возможность назвать фрагмент файла так, что бы через год-два не гадать - что содержит файл с именем "#23from100". Имя файла - это информация для пользователя и ОС, и разработчику туда лезть незачем. Тем более, что это накладывает весьма существенные ограничения на работу и алгоритм программы. Понятно, что это ИМХО.
.......
гарантируя, что в случае потерь информации пользователь будет уведомлен о этом.
У пользователя обязательно должна быть возможность управлять выводом имени файла. И опираться на какие либо закономерности программист не может.
Почему? Потому что - "порезать" файл - нужно не просто порезать, а разместить на носителях для передачи (либо для хранения). А если предполагается возможность хранения - необходимо дать пользователю возможность назвать фрагмент файла так, что бы через год-два не гадать - что содержит файл с именем "#23from100". Имя файла - это информация для пользователя и ОС, и разработчику туда лезть незачем. Тем более, что это накладывает весьма существенные ограничения на работу и алгоритм программы. Понятно, что это ИМХО.
.......
гарантируя, что в случае потерь информации пользователь будет уведомлен о этом.
Индийский код??... Индийский код -- это писаки вроде [color=darkblue]if (booleanValue.toString().equals("true")) return true; ...[/color]
иными словами "наворачивание" кода для решения простой задачи.
Я же решаю именно ту задачу которая поставлена и так как она поставлена. Никакой отсебятины, используя минимальное количество действий и кодописания.
Говорите у пользователя обязательно должна быть возможность управлять выводом имени файла? Зачем? всё что нужно пользователю -- это нарезать файл а потом склеить обратно, желательно чтобы при этом прога сделала всё сама, а вы хотите ещё заставить пользователя делать лишние телодвижения (вводить имя файла или ещё лучше шаблон имени), да зачем ему это надо?
Вы правы что "Имя файла - это информация для пользователя и ОС, и разработчику туда лезть незачем". Поэтому если пользователь уже однажды дал имя файлу то и не зачем заставлять его делать это ещё раз, а просто взять исходное имя и снабдить его номерами кусков. Всё. что может быть проще?
И номера кусков в имени вместе с количеством точно также как любые метаданные внутри файла позволяют отслеживать потерю данных, при этом мы получаем еще дополнительное удобство в том что целостность набора файлов можно определить визуально. не запуская прогу вообще (если файлов немного конечно; если много -- тогда в нарезке вообще мало смысла: не понятно что юзеру делать потом с этим хламом)
Ну это конечно же все ИМХО...
Цитата: LM(AL/M)
Индийский код??... Индийский код -- это писаки вроде [color=darkblue]if (booleanValue.toString().equals("true")) return true; ...[/color]
иными словами "наворачивание" кода для решения простой задачи.
иными словами "наворачивание" кода для решения простой задачи.
нет. "индийский код" - это именно код - "как сказали так и сделал". Приведенный тобой пример - это кстати творческое развитие именно твоего подхода.
Цитата: LM(AL/M)
Говорите у пользователя обязательно должна быть возможность управлять выводом имени файла? Зачем? всё что нужно пользователю -- это нарезать файл а потом склеить обратно, желательно чтобы при этом прога сделала всё сама, а вы хотите ещё заставить пользователя делать лишние телодвижения (вводить имя файла или ещё лучше шаблон имени), да зачем ему это надо?
есть существенная разница - между "заставить" и "дать возможность".
Цитата: LM(AL/M)
И номера кусков в имени вместе с количеством точно также как любые метаданные внутри файла позволяют отслеживать потерю данных, при этом мы получаем еще дополнительное удобство в том что целостность набора файлов можно определить визуально.
угу. а гроссбух у бухгалтера - это дополнительное удобство - не надо вообще включать компьютер. Вот лично мне было бы интересно заставить прочувствовать "дополнительное удобство" на глазок проверив целостность 500 Гб файла записанного на DVD-диски. Ну а так конечно идея генитальна.
Цитата: kot_
нет. "индийский код" - это именно код - "как сказали так и сделал". Приведенный тобой пример - это кстати творческое развитие именно твоего подхода.
смотря кто развивает... но это уже трёп
Цитата: kot_
есть существенная разница - между "заставить" и "дать возможность".
нужна будет возможность "дать возможность" -- дадим, это никак не поломает исходный алгоритм
Цитата: kot_
угу. а гроссбух у бухгалтера - это дополнительное удобство - не надо вообще включать компьютер. Вот лично мне было бы интересно заставить прочувствовать "дополнительное удобство" на глазок проверив целостность 500 Гб файла записанного на DVD-диски. Ну а так конечно идея генитальна.
вы сознательно пропустили в цитате мою оговорку насчёт случая с большим количеством кусков или просто не заметили? в любом случае хотелось бы узнать какова польза от разбиения 500 Гб файла на 4-Гб кусочки. Что вы с ними будете делать ? На DVD записывать? а дальше? ну хорошо, не получится в этом случае на глазок проверить все ли куски есть. трагедия? не думаю -- в этом случае воспользуемся функционалом проги. Одним словом, про 500 гб -- это притянуто за уши как-то
А ты какие файлы резать то собрался? 5 мб что бы на дискету влезали? :)
21 век на дворе - если не в курсе.
Но суть даже не в этом. По поводу исходного алогоритма (который у тебя ничто не поломает) - так а целостность ты как собрался проверять? Дописывать в имя исходный размер в байтах? Или хеш? Или эти проблемы твоя программа вообще не рассматривает? А если пользователю (да хрен с ним, с пользователем, нормальные люди для себя программы пишут) - так если тебе надо будет примечание например добавить? Тоже алгоритм не поломается?
Вот поэтому этот подход и называется "индийским". Плохо тут не то, что неизвестный герой, как ты выразился, код наворачивал. Плохо то, что он использовал инструменты и методы для этого не предназначенные - при наличии гораздо более простых.
Смысл программы не в лаконичности кода - и даже не столько в том, как она решает конкретную задачу - хотя не сомненно это очень важный показатель. Но задачи имеют свойство со временем видоизменятся - и твое предложение использовать имя файла (потому что это просто) - как раз тот случай, когда простота - хуже воровства.
Ну и опять же - проверка целостности файла - это то, что входит в задачу изначально (забудем про имена, примечания - это в принципе может быть не важным) - но задача не в том что бы порезать - задача в том что бы собрать потом. И гарантировать, что в случае наличия ошибок - об этих ошибках надо сообщить. И ошибка - это не только отсуствие файла. Каким образом это будет происходить в твоем "алгоритме"?
21 век на дворе - если не в курсе.
Но суть даже не в этом. По поводу исходного алогоритма (который у тебя ничто не поломает) - так а целостность ты как собрался проверять? Дописывать в имя исходный размер в байтах? Или хеш? Или эти проблемы твоя программа вообще не рассматривает? А если пользователю (да хрен с ним, с пользователем, нормальные люди для себя программы пишут) - так если тебе надо будет примечание например добавить? Тоже алгоритм не поломается?
Вот поэтому этот подход и называется "индийским". Плохо тут не то, что неизвестный герой, как ты выразился, код наворачивал. Плохо то, что он использовал инструменты и методы для этого не предназначенные - при наличии гораздо более простых.
Смысл программы не в лаконичности кода - и даже не столько в том, как она решает конкретную задачу - хотя не сомненно это очень важный показатель. Но задачи имеют свойство со временем видоизменятся - и твое предложение использовать имя файла (потому что это просто) - как раз тот случай, когда простота - хуже воровства.
Ну и опять же - проверка целостности файла - это то, что входит в задачу изначально (забудем про имена, примечания - это в принципе может быть не важным) - но задача не в том что бы порезать - задача в том что бы собрать потом. И гарантировать, что в случае наличия ошибок - об этих ошибках надо сообщить. И ошибка - это не только отсуствие файла. Каким образом это будет происходить в твоем "алгоритме"?
Цитата: kot_
А ты какие файлы резать то собрался? 5 мб что бы на дискету влезали? :)
21 век на дворе - если не в курсе.
21 век на дворе - если не в курсе.
в 21-м веке уж точно никто не станет возиться с записью сотни другой CD/DVD болванок... Типичное применение нарезающих утилит -- это раскидать образ DVD на флэхи или CD или порезать какой нибудь архив для пересылке по сети (напр. чтобы преодолеть ограничение какого нибудь сервера на размер файла и тд). так что число кусков редко бывает > 10
Цитата: kot_
Но суть даже не в этом. По поводу исходного алогоритма (который у тебя ничто не поломает) - так а целостность ты как собрался проверять? Дописывать в имя исходный размер в байтах? Или хеш? Или эти проблемы твоя программа вообще не рассматривает? А если пользователю (да хрен с ним, с пользователем, нормальные люди для себя программы пишут) - так если тебе надо будет примечание например добавить? Тоже алгоритм не поломается?
Вот поэтому этот подход и называется "индийским". Плохо тут не то, что неизвестный герой, как ты выразился, код наворачивал. Плохо то, что он использовал инструменты и методы для этого не предназначенные - при наличии гораздо более простых.
Смысл программы не в лаконичности кода - и даже не столько в том, как она решает конкретную задачу - хотя не сомненно это очень важный показатель. Но задачи имеют свойство со временем видоизменятся - и твое предложение использовать имя файла (потому что это просто) - как раз тот случай, когда простота - хуже воровства.
Ну и опять же - проверка целостности файла - это то, что входит в задачу изначально (забудем про имена, примечания - это в принципе может быть не важным) - но задача не в том что бы порезать - задача в том что бы собрать потом. И гарантировать, что в случае наличия ошибок - об этих ошибках надо сообщить. И ошибка - это не только отсуствие файла. Каким образом это будет происходить в твоем "алгоритме"?
Вы мне тут уже который пост правите про проверку целостности файла, но неужели вы думаете что это будет такая проблема для моего подхода дописать процедуру подсчёта контрольной суммы (любого вида)? Любая более-менее сложная задача разбивается на подзадачи, я рассмотрел одну подзадачу, проверка целостности -- другая подзадача и добавить отдельный юнит для этой цели мне не составит никакого труда. В чём проблема?
Только вы так и не ответили на исходный вопрос: что даёт эмбеддинг ссылки на следующий кусок в сам файл для обеспечения целостности (см. посты №15,19,21)? Я имею в виду в чём выигрыш?
Цитата: LM(AL/M)
в 21-м веке уж точно никто не станет возиться с записью сотни другой CD/DVD болванок... Типичное применение нарезающих утилит -- это раскидать образ DVD на флэхи или CD или порезать какой нибудь архив для пересылке по сети (напр. чтобы преодолеть ограничение какого нибудь сервера на размер файла и тд). так что число кусков редко бывает > 10
ну что за бред? У тебя на руках есть статистика? Или это из разряда "мне кажется"? Так если кажется - крестится надо, гласит народная мудрость. И в этом случае она права.
Даже без относительно того - будет больше 10 файлов или не будет - факт остается - в твоем случае проверка - целиком ручной труд. Понятно что можно пользовать регекспы, находить в имени номер части, находить в имени количество частей... кто там говорил о дополнительном коде? АСЬ?
Я еще раз повторю - не всегда самое простое решение - действительно самое простое.
Цитата: LM(AL/M)
Вы мне тут уже который пост правите про проверку целостности файла, но неужели вы думаете что это будет такая проблема для моего подхода дописать процедуру подсчёта контрольной суммы (любого вида)? Любая более-менее сложная задача разбивается на подзадачи, я рассмотрел одну подзадачу, проверка целостности -- другая подзадача и добавить отдельный юнит для этой цели мне не составит никакого труда. В чём проблема?
проблемы нет. у того неизвестно индуса, код которого ты привел, тоже видимо задача разбивалась на две. Он тоже видимо настолько продвинутый кодер.
А я например утверждаю, что любая попытка "решать" таким образом задачу приводит к появлению в программе громадного количества "костылей" и несуразностей. Например, как будет в твоем решении реализована проверка MD5-хеша? Да даже и просто контрольная сумма - ее тоже как бы желательно хранить, иначе как ее проверять? Тоже пихнешь ее в имя? Да и желательно хеш целого файла сохранить бы - после сборки его тоже как бы неплохо проверить. А ты продолжаешь твердить заученно про "подзадачи". Да задача разбивается на подзадачи - но только после того, как четко сформулирована цель. А цель - мой юный падаван - вовсе не в том, чтобы файл разрезать (я это уже говорил, повторю для тех кто упустил), а в том, что бы после этой операции была возможность его корректно собрать. И исходя из этой цели, надо формулировать задачи и продумывать средства для их реализации. А иначе получается "индийский" код.
Понятно, что можно при желании и просто обойтись именами файлов, как ты и предлагаешь, но как говоривал один мой знакомый прапорщик - сдуру можно и коня вы...ть.
Цитата: LM(AL/M)
надеюсь выше ответил.
Цитата: kot_
надеюсь выше ответил.
вобще-то нет... всё что выше -- очередное повторонеие сказанного раньше только другими словами
по-моему тема исчерпана