Valentin Davydov wrote: > > > > VD> osync Pad the final output block to the full output block size. If > > VD> the input file is not a multiple of the out- put block size after > > VD> conversion, this conversion forces the final output block to be the > > VD> same size as preceding blocks for use on devices that require > > VD> regularly sized blocks to be written. This option is incompatible > > VD> with use of the bs=n block size specification. > > > >Я ведь не поленился провести эксперимент с osync. Сделал файл некратного > >размера 1048577 байт. При попытке его "dd bs=64k" возникает ошибка > >"(sa0:sym0:0:5:0): Invalid request. Variable block device requests must be > >between 4 and 16777212 bytes" > > > >Ладно, применяем способ с osync. > > > >dd if=sobaka of=$TAPE conv=osync obs=64k
> А без obs проборвал?
Без obs стример начинает медленно писать и дрочить ленту. 512-байтные блоки видимо не нравятся ему.
> >файл конечно записался без сообщений об ошибках, но... это уже не тот файл. При > >считывании его с ленточки он удлинился и md5 стал другой.
> Ещё бы. Hасколько мне известно, коллизиq MD5 разной длины пока что не нашли.
> >Так что либо я совет воспользоваться osync как-то неправильно понял,
> Всё правильно ты понял. Хочешь писать на ленту ddой - используй osync.
> >или это > >вредительский совет. Если tar и способен распознать паддинг в конце архива, то > >с произвольным файлом так поступать ни в коем случае нельзя.
> Ты таки удивишься, но твой bzip2-архив тоже не испортится от паддинга в > конце. Равно как и документы Microsoft Office (что старого, что нового > формата), образа известных файловых систем, JPEG-картинки и всякие прочие > вполне произвольные файлы. Более того, я навскидку и не могу привести пример > файла, который бы испортился от этого. Разве что какой-нибудь подписанный > opaque blob.
