С переходом на KDE я проникся величием ее штатного писала - программы k3b (каковая, конечно, просто графический фронт-энда над связкой из mkisofs и cdrecord). И если массированную запись дисков (например, при тотальных backup'ах) все равно делал из командной строки, то для "сболванивания" единичных дисков стал все чаще применять именно k3b. А поскольку с появлением всякого рода внешних винчестеров необходимость в массированном "оболванивании" возникала все реже, я со временем начал забывать, как вообще обращаются с инструментами пакета cdrtools. А когда пришлось вспомнить - оказалось, что кое-что в нем изменилось.

Однако недавно вынужденно пришлось предаться ностальгии - после установки на ноутбук Xubuntu Feisty и срочной потребности записать из него пару дисков.

В штатном комплекте Xubuntu CD/DVD-писало предусмотрено - это программа XFburn, составляющая часть интегрированной среды XFce (напомню, что именно этот десктоп и определяет специфику дистрибутива Xubuntu).

Программа XFburn выглядит непритязательно (рис. 1) - вы не увидите здесь функций создания аудио-компактов, кодирования видео, форматирования DVD (для использования с файловой системой UDF, допускающей обращение с DVD-болванкой как очень большой дискетой). Да что там UDF - не было даже возможности записать банальный DVD в ISO-формате...

Однако минимально необходимый набор функций - очистки CD-RW, копирования компакта и записи уже готового образа, - были доступны через кнопки инструментальной панели или через меню Actions (рис. 2).

Можно было и собрать свой диск из произвольного набора файлов - опять же посредством кнопки или через меню File. Как и в любой аналогичной программе, для этого достаточно было перетащить нужные файлы и каталоги из файлового древа в поле проекта и нажать кнопку Burn Composition (рис. 3). В появляющемся окне можно было полюбоваться на свой привод (если он опознался правильно), выставить желаемую скорость записи (опции автоматического определения таковой, правда, не имеется) и ее режим, задать некоторые дополнительные опции (рис. 4). Среди коих - возможность ограничиться только созданием образа диска, без его записи.

Я честно проделал все эти манипуляции для требуемого мне набора данных, после чего опять без тени сомнения нажал на кнопку Burn Composition. Каково же было мое удивление, когда вместо наблюдения за процессом записи я имел счастье лицезреть сообщение об отсутствии SCSI-драйвера!

"Какой, к чертям собачьим, SCSI-драйвер" - подумал я. Ведь компакты в Linux уже давно болванятся напрямую, через ATA-интерфес, без всякой эмуляции SCSI-шины. И полез в настройки программы (через меню Edit -> Preferences).

Однако и это ничего не дало: ни на первой (рис. 5), ни на второй (рис. 6) странице настроечной панели я не нашел никакого подходящего переключателя. Оставалось только в очередной раз произнести сакраментальную фразу сибирских мужиков, впервые увидевших японскую мотопилу, вспомнить, что в любой ситуации у POSIX'ивиста один выход всегда остается.

В данном случае им был интерфейс командной строки для прямого создания диска через утилиты пакета cdrtools. Быстро сварганив iso-образ из нужных мне данных командой mkisofs, я набрал команду cdrecord для его записи - и тут-то и оказалось, что я напрочь забыл, что там следует вбивать далее. Точнее, кое-что я помнил. Например, что нужно указать опцию -v (от verbose), дабы наблюдать за ходом процесса, путь к файлу образа и его имя, а также имя файла устройства для записи в странной системе именования SCSI-устройств. Однако смутно припоминаемое устройство dev=ATAPI:0,0,0 работать отказалось, сославшись на отсутствие все того же режима эмуляции SCSI.

Это становилось интересным - возможно, я неправильно указал номер устройства? Для установления оного, как известно, служит опция --scanbus команды cdrecord. Разумеется, в форме

$ sudo cdrecord --scanbus

я не получил ничего, кроме сообщения об ошибке:

cdrecord: No such file or directory. 
Cannot open SCSI driver!
For possible targets try 'wodim -scanbus'.
For possible transport specifiers try 'wodim dev=help'.
For IDE/ATAPI devices configuration, see the file README.ATAPI.setup 
from the wodim documentation.

Но такое же сообщение последовало и на команду

sudo cdrecord -scanbus dev=ATAPI

Точнее, сообщение было другое -

cdrecord: No write mode specified.

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

$ cdrecord dev=help

Из ее вывода я узнал, что, помимо транспорта SCSI (sg) и ATAPI, существует также транспорт ATA, target которого записывается также, как и для "урожденного" SCSI: bus,target,lun, то есть без указания имени транспорта, как для ATAPI. Опробовав его командой

$ sudo cdrecord --scanbus dev=ATA

я получил имя для своего устройства.

scsibus1:
        1,0,0   100) 'HL-DT-ST' 'DVD-RW GWA-4082N' 'CW02' Removable CD-ROM
        1,1,0   101) *
        1,2,0   102) *
        1,3,0   103) *
        1,4,0   104) *
        1,5,0   105) *
        1,6,0   106) *
        1,7,0   107) *

После чего с помощью команды

$ sudo cdrecord -v dev=1,0,0 patH5/imagename.iso

диск был наконец благополучно записан.

Интересно, что после выполнения этой процедуры и Xfburn начал записывать диски - видимо, он подхватил настройки от cdrtools.

В общем, можно видеть, что правила обращения с утилитой cdrecord время от времени меняются - собственно, об этом открытым текстом сказано в документации к cdrtools. И потому я сочинил очередную шпаргалку по записи компактов - для себя и для тех, кто начинает забывать, сколько склерозов они должны были купить в кондитерском отделе. И на случай, если использование графических фронт-эндов типа k3b почему-либо невозможно или нежелательно. Следует помнить только одно: шпаргалка эта действенна на текущий момент, в будущем, возможно, в пакете cdrtools опять чего-нибудь поменяется. Итак,

Собственно, шпаргалка

1. Создание образа диска - даже здесь кое-что изменилось:

$ mkisofs -R -J -o imagename.iso patH5data

Здесь опция -R обеспечивает поддержку расширения Rock Ridge, позволяющего воспроизводить в файловой системе ISO9660 длинные имена файлов, множественные точки в них, а также сохранить на записанном CD атрибуты принадлежности и доступа, свойственные файловым системам Unix-типа, в первозданном виде. То есть вывод команды

ls -l mountpoint/

drwxr-xr-x  3 alv alv 2048 2007-01-09 22:05 boot_init
drwxr-xr-x  2 alv alv 2048 2007-01-09 22:02 crux

Вместо опции -R можно использовать опцию -r. Она также включает поддержку расширения Rock Ridge, но обнуляет атрибуты принадлежности юзеру и группе, а также устанавливает бит чтения для всех - пользователя, группы и прочих. В результате вывод команды

ls -l mountpoint/

примет следующий вид:

dr-xr-xr-x  3 root root 2048 2007-01-09 22:05 boot_init
dr-xr-xr-x  2 root root 2048 2007-01-09 22:02 crux

Из этого можно видеть, что в полях пользователя и группы фигурируют имена не хозяев оригинальных файлов, а того пользователя, который смонтировал CD или его образ (если в файле /etc/fstab не прописано иное, и то, и другое может сделать только суперпользователь).

Кстати, смонтировать образ диска для проверки его содержимого можно командой

$ sudo mount -o loop patH5/imagename.iso mountpoint

Опция -J обеспечивает поддержку так называемого расширения Joliet, позволяющего видеть в Windows длинные имена файлов - чистый стандарт ISO9660 предусматривает только имена файлов в DOS-формате 8.3. Если среди них, к тому же, имеются и имена в национальных кодировках, то следует использовать опцию -joliet-long, она позволяет сохранять имен длиной до 103 символов в Unicode. Монтировать образы, созданные с этой опцией (как и записанные с них диски), следует с опцией uft8:

$ sudo mount -o loop -o uft8 patH5/imagename.iso mountpoint

Насколько мне помнится, опций -r и -joliet-long команда mkisofs ранее не имела. Или я просто не обращал на них внимания? Первая представляется очень удобной, если требуется тиражирование собственных данных. Полезность второй оценят, наверное, те, кто дает файлам кириллические имена (автор этих строк к их числу не принадлежит).

2. Определение имени записывающего устройства:

$ sudo cdrecord --scanbus dev=ATA

что должно дать на выводе нечто вроде этого:

scsibus1:
        1,0,0   100) 'HL-DT-ST' 'DVD-RW GWA-4082N' 'CW02' Removable CD-ROM
        1,1,0   101) *

и так далее.

3. Собственно запись:

$ sudo cdrecord -v dev=1,0,0 patH5/imagename.iso

Здесь дополнительно возможны следующие опции:

• speed=## - задает принудительно скорость записи; при ее отсутствии запись происходит на скорости, максимально возможной для данного привода и болванки, и потому ее имеет смысл задавать только с целью понижения, если запись на высоких скоростях почему-либо не проходит;
• -eject - выдвижение лотка (или выталкивание болванки из приводов щелевого типа) по окончании записи.

4. Очистка перезаписываемых дисков:

$ sudo cdrecord -v blank=fast dev=0,0,0

для "быстрой" очистки (удаляется только оглавление диска),

$ sudo cdrecord -v blank=all dev=0,0,0

выполняет полную его очистку,

$ sudo cdrecord -v blank=session dev=0,0,0

стирает только последнюю сессию (при мультисессионной записи),

$ sudo cdrecord -v blank=unclose dev=0,0,0

"отрывает" закрытую сессию, позволяя производить дозапись на "закрытый" ранее диск. Кстати, таких возможностей (стирания сессии и "открытия диска") я в прежние времена тоже не припоминаю.

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

На записи DVD я здесь останавливаться не буду: в промышленных масштабах я этим еще не занимался, а единичные диски проще писать через фронт-энды.

Автор: Алексей Федорчук
Источник: www.citkit.ru