= Сообщение: 1443 из 10763 ===================================== RU.UNIX.BSD = От : Valentin Nechayev 2:5020/400 13 May 14 12:28:19 Кому : Victor Sudakov 13 May 14 12:28:19 Тема : Re: Прикол с ленточкой FGHI : area://RU.UNIX.BSD?msgid=<1187487569@segfault.kiev.ua>+7fc6a9aa На : area://RU.UNIX.BSD?msgid=2:5005/49+5371780f = Кодировка сообщения определена как: CP866 ================================== ============================================================================== From: Valentin Nechayev <netch@segfault.kiev.ua>
>>> Victor Sudakov wrote:
VS> Как раз не очень понятно. Дисковый блок бывает разный, вот в UFS он может быть VS> от 4096 и выше. Предлагаешь выяснять размер блока на данном конкретном диске VS> перед паддингом?
В описании файла на диске в иноде есть его размер в байтах. В описании файла _внутри_ tar - тоже. Hо если ты пишешь просто блоками, то вынужден дополнить до нужного размера.
Точно такой же эффект был бы, если бы ты писал zip-архив или любой другой файл напрямую на диск, без файловой системы, а метку конца файла (которая обозначается особой последовательностью, гарантированно отличаемой от данных) эмулировал бы, например, данными на другом диске, или писал в SMART.
VD>> А сетевая шара - слишком высокого уровня абстракция, там и лок-то VD>> (который lock) толком не определён, не то что блок. VS> Hа одном диске ufs создавалась с -b16384, на другом c -b4096, по-твоему от VS> переноса диска на диск одного и того же zip архива паддинг может становиться то VS> правильным, то неправильным?
При переносе между разными UFS сохраняется указанный в иноде размер файла. При прямой работе с устройством такой возможности нет, её надо обеспечивать самому.
VS> Я провел аналогичный эксперимент, методом половинного деления пытался выяснить, VS> после какого размера паддинга архив перестает читаться.
VS> При count=73000 еще читается, при count=74000 уже перестает. Числа нарочно VS> круглые, а не степени двойки или размеры каких-то гипотетических блоков. Дальше VS> стало лень, но появилось предположение, что "паддинг до целого блока" или "до VS> степени двойки" тут ни при чем, а просто у zip есть некоторая терпимость к VS> нулям в конце архива, но она не безгранична.
Вполне возможно. Что тебе мешает посмотреть это в исходниках unzip?
--netch-- --- ifmail v.2.15dev5.4 * Origin: Dark side of coredump (2:5020/400)
