From fe5c734d9030a7aee34428345429cc7ff7518b11 Mon Sep 17 00:00:00 2001 From: Johnny Hughes Date: Wed, 2 Oct 2024 16:57:40 +0000 Subject: [PATCH] dvdplusrw-tools package is retired on branch c10s for CS-2551 --- .gitignore | 1 - README.md | 3 + dead.package | 1 + dvd+rw-tools-7.0-dvddl.patch | 13 - dvd+rw-tools-7.0-glibc2.6.90.patch | 11 - dvd+rw-tools-7.0-reload.patch | 12 - dvd+rw-tools-7.0-wctomb.patch | 11 - dvd+rw-tools-7.0-wexit.patch | 11 - dvd+rw-tools-7.0.manpatch | 27 - dvd+rw-tools-7.1-bluray_pow_freespace.patch | 14 - dvd+rw-tools-7.1-bluray_srm+pow.patch | 12 - dvd+rw-tools-7.1-format.patch | 251 ---- dvd+rw-tools-7.1-lastshort.patch | 12 - dvd+rw-tools-7.1-noevent.patch | 19 - dvd+rw-tools-7.1-sysmacro-inc.patch | 10 - dvd+rw-tools.spec | 222 ---- index.html | 1295 ------------------- sources | 1 - 18 files changed, 4 insertions(+), 1922 deletions(-) delete mode 100644 .gitignore create mode 100644 README.md create mode 100644 dead.package delete mode 100644 dvd+rw-tools-7.0-dvddl.patch delete mode 100644 dvd+rw-tools-7.0-glibc2.6.90.patch delete mode 100644 dvd+rw-tools-7.0-reload.patch delete mode 100644 dvd+rw-tools-7.0-wctomb.patch delete mode 100644 dvd+rw-tools-7.0-wexit.patch delete mode 100644 dvd+rw-tools-7.0.manpatch delete mode 100644 dvd+rw-tools-7.1-bluray_pow_freespace.patch delete mode 100644 dvd+rw-tools-7.1-bluray_srm+pow.patch delete mode 100644 dvd+rw-tools-7.1-format.patch delete mode 100644 dvd+rw-tools-7.1-lastshort.patch delete mode 100644 dvd+rw-tools-7.1-noevent.patch delete mode 100644 dvd+rw-tools-7.1-sysmacro-inc.patch delete mode 100644 dvd+rw-tools.spec delete mode 100644 index.html delete mode 100644 sources diff --git a/.gitignore b/.gitignore deleted file mode 100644 index 5908d88..0000000 --- a/.gitignore +++ /dev/null @@ -1 +0,0 @@ -dvd+rw-tools-7.1.tar.gz diff --git a/README.md b/README.md new file mode 100644 index 0000000..24b9ea2 --- /dev/null +++ b/README.md @@ -0,0 +1,3 @@ +# Package Not Available +This package is not available on CentOS Stream 10. +It may be available on another branch. \ No newline at end of file diff --git a/dead.package b/dead.package new file mode 100644 index 0000000..190f9ce --- /dev/null +++ b/dead.package @@ -0,0 +1 @@ +dvdplusrw-tools package is retired on branch c10s for CS-2551 \ No newline at end of file diff --git a/dvd+rw-tools-7.0-dvddl.patch b/dvd+rw-tools-7.0-dvddl.patch deleted file mode 100644 index c1c6fb3..0000000 --- a/dvd+rw-tools-7.0-dvddl.patch +++ /dev/null @@ -1,13 +0,0 @@ ---- ./growisofs_mmc.cpp.joe 2006-04-27 20:45:00.788446635 +0200 -+++ ./growisofs_mmc.cpp 2006-04-27 20:46:01.666824300 +0200 -@@ -1412,9 +1412,7 @@ - blocks += 15, blocks &= ~15; - - if (blocks <= split) -- fprintf (stderr,":-( more than 50%% of space will be *wasted*!\n" -- " use single layer media for this recording\n"), -- exit (FATAL_START(EMEDIUMTYPE)); -+ fprintf (stderr,":-? more than 50%% of space will be *wasted*!\n"); - - blocks /= 16; - blocks += 1; diff --git a/dvd+rw-tools-7.0-glibc2.6.90.patch b/dvd+rw-tools-7.0-glibc2.6.90.patch deleted file mode 100644 index 49742d3..0000000 --- a/dvd+rw-tools-7.0-glibc2.6.90.patch +++ /dev/null @@ -1,11 +0,0 @@ -diff -up dvd+rw-tools-7.0/transport.hxx.glibc2.6.90 dvd+rw-tools-7.0/transport.hxx ---- dvd+rw-tools-7.0/transport.hxx.glibc2.6.90 2007-08-15 12:56:17.000000000 +0200 -+++ dvd+rw-tools-7.0/transport.hxx 2007-08-15 12:56:42.000000000 +0200 -@@ -11,6 +11,7 @@ - #include - #include - #include -+#include - #include - #include - #include diff --git a/dvd+rw-tools-7.0-reload.patch b/dvd+rw-tools-7.0-reload.patch deleted file mode 100644 index 49352e5..0000000 --- a/dvd+rw-tools-7.0-reload.patch +++ /dev/null @@ -1,12 +0,0 @@ -diff -Nrup dvd+rw-tools-7.0/growisofs_mmc.cpp dvd+rw-tools-7.0_mod/growisofs_mmc.cpp ---- dvd+rw-tools-7.0/growisofs_mmc.cpp 2006-09-23 20:45:49.000000000 +0800 -+++ dvd+rw-tools-7.0_mod/growisofs_mmc.cpp 2007-11-19 18:20:46.000000000 +0800 -@@ -138,7 +138,7 @@ int media_reload (char *name=NULL,struct - cmd[0] = 0x1B; // START/STOP UNIT - cmd[4] = 0x2; // "Eject" - cmd[5] = 0; -- if (cmd.transport()) return 1; -+ cmd.transport(); - } - #if defined(__sun) || defined(sun) - else if (volmgt_running()) diff --git a/dvd+rw-tools-7.0-wctomb.patch b/dvd+rw-tools-7.0-wctomb.patch deleted file mode 100644 index 56bd725..0000000 --- a/dvd+rw-tools-7.0-wctomb.patch +++ /dev/null @@ -1,11 +0,0 @@ ---- transport.hxx~ 2008-03-25 21:24:47.000000000 -0400 -+++ transport.hxx 2008-03-25 21:25:36.000000000 -0400 -@@ -116,7 +116,7 @@ - extern "C" char *plusminus_locale() - { static class __plusminus { - private: -- char str[4]; -+ char str[MB_LEN_MAX]; - public: - __plusminus() { setlocale(LC_CTYPE,ENV_LOCALE); - int l = wctomb(str,(wchar_t)(unsigned char)'±'); diff --git a/dvd+rw-tools-7.0-wexit.patch b/dvd+rw-tools-7.0-wexit.patch deleted file mode 100644 index e7910cb..0000000 --- a/dvd+rw-tools-7.0-wexit.patch +++ /dev/null @@ -1,11 +0,0 @@ ---- dvd+rw-tools-7.0/dvd+rw-format.cpp.wexit 2007-06-21 12:42:30.000000000 +0200 -+++ dvd+rw-tools-7.0/dvd+rw-format.cpp 2007-06-21 12:44:13.000000000 +0200 -@@ -245,7 +245,7 @@ int main (int argc, char *argv[]) - alarm(1); - while ((waitpid(pid,&i,0) != pid) && !WIFEXITED(i)) ; - if (WEXITSTATUS(i) == 0) fprintf (stderr,"\n"); -- exit (0); -+ exit (WEXITSTATUS(i)); - } - #endif - diff --git a/dvd+rw-tools-7.0.manpatch b/dvd+rw-tools-7.0.manpatch deleted file mode 100644 index cbbade4..0000000 --- a/dvd+rw-tools-7.0.manpatch +++ /dev/null @@ -1,27 +0,0 @@ -diff -ur dvd+rw-tools-7.0/Makefile.m4 dvd+rw-tools-7.0-manpatch/Makefile.m4 ---- dvd+rw-tools-7.0/Makefile.m4 2006-09-24 19:55:19.000000000 +0200 -+++ dvd+rw-tools-7.0-manpatch/Makefile.m4 2006-10-09 10:44:31.000000000 +0200 -@@ -191,7 +191,7 @@ - LINK.o =$(LINK.cc) - - prefix?=/usr/local --manprefix?=$(shell case $(prefix) in (*/usr/?*) echo $(prefix)/man ;; (*) echo $(prefix)/share/man ;; esac) -+mandir?=$(shell case $(prefix) in (*/usr/?*) echo $(prefix)/man ;; (*) echo $(prefix)/share/man ;; esac) - - bin_mode?=0755 # yes, default is *no* set-uid - minus_o:=$(shell [[ `id -u` == 0 ]] && echo "-o root") -@@ -199,10 +199,10 @@ - install: dvd+rw-tools - [[ -d $(prefix)/bin ]] || mkdir -p $(prefix)/bin - install $(minus_o) -m $(bin_mode) $(CHAIN) $(prefix)/bin -- [[ -d $(manprefix)/man1 ]] || mkdir -p $(manprefix)/man1 -- install $(minus_o) -m 0644 growisofs.1 $(manprefix)/man1 -- -[[ -f rpl8 ]] && install $(minus_o) -m $(bin_mode) rpl8 $(prefix)/bin; : -- -[[ -f btcflash ]] && install $(minus_o) -m $(bin_mode) btcflash $(prefix)/bin; : -+ [[ -d $(mandir)/man1 ]] || mkdir -p $(mandir)/man1 -+ install $(minus_o) -m 0644 growisofs.1 $(mandir)/man1 -+ -[[ -f rpl8 ]] && install $(minus_o) -m $(bin_mode) rpl8 $(prefix)/bin || : -+ -[[ -f btcflash ]] && install $(minus_o) -m $(bin_mode) btcflash $(prefix)/bin || : - ]) - - # common section diff --git a/dvd+rw-tools-7.1-bluray_pow_freespace.patch b/dvd+rw-tools-7.1-bluray_pow_freespace.patch deleted file mode 100644 index 3b56282..0000000 --- a/dvd+rw-tools-7.1-bluray_pow_freespace.patch +++ /dev/null @@ -1,14 +0,0 @@ -diff -up wrk/growisofs_mmc.cpp.wrk wrk/growisofs_mmc.cpp ---- wrk/growisofs_mmc.cpp.wrk 2014-11-14 13:22:49.579552118 +0100 -+++ wrk/growisofs_mmc.cpp 2014-11-14 13:35:36.779730963 +0100 -@@ -410,7 +410,9 @@ static unsigned int get_2k_capacity (Scs - } - - nwa = 0; -- if (buf[7]&1 && !bdr_plus_pow) // NWA_V -+ //if (buf[7]&1 && !bdr_plus_pow) // NWA_V -+ //!bdr_plus_pow patched out for Fedora -+ if (buf[7]&1) // NWA_V - { nwa = buf[12]<<24; - nwa |= buf[13]<<16; - nwa |= buf[14]<<8; diff --git a/dvd+rw-tools-7.1-bluray_srm+pow.patch b/dvd+rw-tools-7.1-bluray_srm+pow.patch deleted file mode 100644 index 8fc1a6d..0000000 --- a/dvd+rw-tools-7.1-bluray_srm+pow.patch +++ /dev/null @@ -1,12 +0,0 @@ -diff -up dvd+rw-tools-7.1/growisofs_mmc.cpp.wrk dvd+rw-tools-7.1/growisofs_mmc.cpp ---- dvd+rw-tools-7.1/growisofs_mmc.cpp.wrk 2013-06-24 14:18:38.898344970 +0200 -+++ dvd+rw-tools-7.1/growisofs_mmc.cpp 2013-06-24 14:20:00.428025541 +0200 -@@ -756,6 +756,8 @@ static void bd_r_format (Scsi_Command &c - - wait_for_unit (cmd); - -+ bdr_plus_pow = 1; -+ - cmd[0] = 0x35; // FLUSH CACHE - cmd[9] = 0; - cmd.transport(); diff --git a/dvd+rw-tools-7.1-format.patch b/dvd+rw-tools-7.1-format.patch deleted file mode 100644 index c8a7d11..0000000 --- a/dvd+rw-tools-7.1-format.patch +++ /dev/null @@ -1,251 +0,0 @@ -diff -up dvd+rw-tools-7.1/dvd+rw-format.1.format dvd+rw-tools-7.1/dvd+rw-format.1 ---- dvd+rw-tools-7.1/dvd+rw-format.1.format 2012-08-23 17:30:20.001822268 +0200 -+++ dvd+rw-tools-7.1/dvd+rw-format.1 2012-08-24 09:37:14.549094680 +0200 -@@ -0,0 +1,132 @@ -+.TH DVD+RW\-FORMAT 1 "24 Aug 2012" "dvd+rw\-tools 7.1" -+.SH NAME -+dvd+rw\-format \- formatting and blanking DVD and BD media program. -+.SH SYNOPSIS -+.B dvd+rw\-format -+[\fB\-force\fP[\fB\=full\fP]] -+[\fB\-lead\-out|\-blank\fP[\fB\=full\fP]] -+[\fB\-ssa\fP[\fB\=none|default|max|XXXm\fP]] -+.I /dev/dvd -+ -+.SH DESCRIPTION -+\fBdvd+rw\-format\fP is a part of \fBdvd+rw\-tools\fP suite and allows to -+format virgin DVD+RW or BD\-RE media for the first use or blank already -+written DVD\-RW. -+Typical use cases of using \fBdvd+rw\-format\fP is formatting DVD\-RW to -+make them over\-writable, blanking used DVD\-RW to make them sequentially -+writable from scratch, formatting BD\-RE and DVD\-RAM with custom -+spare area sizes or re\-formatting BD\-RE and DVD\-RAM to change their spare -+size. -+It is not possible to format CD\-RW by \fBdvd+rw\-format\fP, -+you can use \fBcdrskin\fP, \fBxorriso\fP or \fBwodim\fP utilities to blank -+them or cdrwtool to format them instead, see section \fBEXAMPLES\fP. -+ -+A DVD\-RW accepts two disc modes: the \fISequential Recording\fP -+and the \fIRestricted Overwrite\fP. If a DVD\-RW medium is in the latter one, -+it will behave much like DVD+RW. -+By default DVD\-RW discs are in Sequential Recording mode, but -+can be put into Restricted Overwrite mode using \fBdvd+rw\-format\fP -+when no options given. -+Be aware, that only \-blank=full, which lasts as long as full writing, -+makes a used sequential DVD\-RW capable of performing multi\-session, -+while fast blanked DVD\-RW can only do Disk\-At\-Once. -+ -+Virgin DVD\-RW can be directly written without -+the need of a formatting operation, however a non\-virgin DVD\-RW in -+Sequential Recording mode needs to be blanked before writing a new -+initial session. Since a DVD\-RW medium in the Restricted Overwrite -+mode behaves much like DVD+RW, it can be written again without prior -+formatting the media. -+ -+Virgin BD\-RE and DVD+RW media may be initially formatted prior -+usage. Any\-time later, \fBgrowisofs\fP program will take care of formatting -+it automatically whenever appropriate, while further formatting is not -+recommended, however it is possible. -+ -+.SH OPTIONS -+.TP -+.BI \-force[\=full] -+Perform formatting even if the medium is formatted already. This is not -+recommended for BD\-RE and DVD+RW media, since they need to be -+formatted only once. Use \fB\-format=full\fP to perform full (lengthy) -+reformat in case of DVD\-RAM or (lengthy) Full Certification in case of -+BD\-RE. -+.TP -+.BI \-lead\-out -+Relocates the lead\-out next to outermost written sector as well as makes -+sure there is no virgin surface before it. This can make the medium more -+compatible with some DVD players. Previously written data is not -+affected by this operation. -+.TP -+.BI \-blank[\=full] -+Wipe data from DVD\-RW media. Data on BD\-RE and DVD+RW will we overwritten -+automatically, so there is no need to blank them explicitly. -+Use \fB\-blank\=full\fP to change DVD\-RW back to Sequential Recording mode. -+.TP -+.BI \-ssa[\=none|default|max|XXXm] -+Grow, eliminate, reset to default or maximize \fISupplementary Spare Area\fP. -+ -+.SH EXAMPLES -+Actual device names vary from one operating system to another. We use -+\fI/dev/dvd\fP as a collective name or as symbolic link to the actual -+device if you wish. Under Linux it will most likely be a -+device such as "/dev/sr0" or "/dev/hda" for older Linux 2.6. -+ -+To blank a CD\-RW, you have to use another utility, e.g. wodim: -+ -+ \fBwodim\fP \fBblank=fast\fP \-immed dev=\fI/dev/cdrom\fP -+ \fBcdrskin\fP \fBblank=all|fast|as_needed\fP \-immed dev=\fI/dev/cdrom\fP -+ \fBxorriso\fP \fB\-outdev\fP \fI/dev/cdrom\fP \fB\-blank all|fast|as_needed\fP -+ -+To format CD\-RW, you can use cdrwtool: -+ -+ \fBcdrwtool\fP \fB\-d\fP \fI/dev/cdrom\fP \fB\-q\fP -+ -+To blank a DVD\-RW and put in the incremental sequential mode, run: -+ -+ \fBdvd+rw\-format\fP \fB\-blank=full\fP \fI/dev/dvd\fP -+ -+To blank a DVD\-RW and put in the Restricted Overwrite mode, run: -+ -+ \fBdvd+rw\-format\fP \fB\-force\fP \fI/dev/dvd\fP -+ -+To overwrite data of BD\-RE, DVD+RW, DVD\-RW or DVD\-RAM run: -+ -+ \fBgrowisofs\fP \fB\-Z\fP \fI/dev/dvd\fP\=\fI/dev/zero\fP -+ -+To blank a DVD\-RAM, you can use: -+ -+ \fBdd\fP if\=\fI/dev/zero\fP of\=\fI/dev/dvd\fP -+ -+To relocate lead\-out sector, run: -+ -+ \fBdvd+rw\-format\fP \fB\-lead\-out\fP \fI/dev/dvd\fP -+ -+.SH NOTES -+Note that DVD+RW re\-formatting procedure does not substitute for -+blanking. If you want to nullify the media, e.g. for privacy reasons, -+do it explicitly with 'growisofs \-Z \fI/dev/dvd\fP\=\fB/dev/zero\fP'. -+ -+When growisofs "runs into" blank Blu\-ray Disc media or BD\-RE, -+it gets pre\-formatted with minimal spare area size of 256MB. -+ -+.SH SEE ALSO -+Most up\-to\-date information on dvd+rw\-tools is available at -+http://fy.chalmers.se/~appro/linux/DVD+RW/. -+.PP -+.BR growisofs (1), -+.BR cdrskin (1), -+.BR xorriso (1), -+.BR wodim (1), -+.BR cdrwtool (1) -+ -+.SH AUTHORS -+Andy Polyakov stands for programming and on\-line -+information. -+ -+This manpage was created by Honza Horak and consulted by -+Thomas Schmitt . -+ -+.SH LICENSE -+\fBdvd+rw\-format\fP is distributed under GNU GPL. -+ -diff -up dvd+rw-tools-7.1/growisofs.1.format dvd+rw-tools-7.1/growisofs.1 ---- dvd+rw-tools-7.1/growisofs.1.format 2008-03-01 11:40:06.000000000 +0100 -+++ dvd+rw-tools-7.1/growisofs.1 2012-08-24 09:35:55.550780073 +0200 -@@ -113,7 +113,7 @@ recordings. - Actual device names vary from one operating system to another. We use - \fI/dev/dvd\fP as a collective name or as symbolic link to the actual - device if you wish. Under Linux it will most likely be an ide\-scsi --device such as "/dev/scd0." Under NetBSD/OpenBSD it has to be a -+device such as "/dev/sr0." Under NetBSD/OpenBSD it has to be a - \fIcharacter\fP SCSI CD\-ROM device such as "/dev/rcd0c." Under Solaris - it also has to be a \fIcharacter\fP SCSI/ATAPI CD\-ROM device, e.g. - "/dev/rdsk/c0t1d0s2" or "/vol/dev/aliases/cdrom0." And likewise in -@@ -210,11 +210,19 @@ DVD\-RAM or Blu\-ray Disc, as volumes ar - When growisofs "runs into" blank Blu\-ray Disc media, BD\-RE or BD\-R, - it gets pre-formatted with minimal spare area size of 256MB. - -+A DVD\-RW accepts two disc modes: the \fISequential Recording\fP -+and the \fIRestricted Overwrite\fP. If a DVD\-RW medium is in the later one, -+it will behave much like DVD+RW. -+By default DVD\-RW discs are in Sequential Recording mode, but -+can be put into Restricted Overwrite mode using \fBdvd+rw\-format\fP. -+See \fBdvd+rw\-format (1)\fP for more info. -+ - .SH SEE ALSO - Most up-to-date information on dvd+rw\-tools is available at - http://fy.chalmers.se/~appro/linux/DVD+RW/. - .PP --The manpage for \fBmkisofs\fP. -+.BR mkisofs (1), -+.BR dvd+rw\-format (1) - - .SH AUTHORS - Andy Polyakov stands for programming and on-line -diff -up dvd+rw-tools-7.1/growisofs.c.format dvd+rw-tools-7.1/growisofs.c ---- dvd+rw-tools-7.1/growisofs.c.format 2008-03-04 10:15:03.000000000 +0100 -+++ dvd+rw-tools-7.1/growisofs.c 2012-08-23 17:30:20.028822506 +0200 -@@ -3433,8 +3433,15 @@ int main (int argc, char *argv[]) - else if (isatty (0)) warn_for_isofs |= 2; - - if (no_tty_check || (warn_for_isofs&2)) -- fprintf (stderr,"WARNING: %s already carries isofs!\n",in_device), -+ { -+ fprintf (stderr,"WARNING: %s already carries isofs!\n",in_device); -+ /* we cannot re-write a DVD-RW media in Sequential mode */ -+ if ((int)(mmc_profile&0xFFFF) == 0x14) -+ fprintf (stderr,"FATAL: DVD-RW medium is in Sequential mode, you " -+ "need to blank it before writing again.\n"), -+ exit(FATAL_START(EBUSY)); - printf ("About to execute '"); -+ } - else - fprintf (stderr,"FATAL: %s already carries isofs!\n",in_device), - exit(FATAL_START(EBUSY)); -diff -up dvd+rw-tools-7.1/Makefile.format dvd+rw-tools-7.1/Makefile ---- dvd+rw-tools-7.1/Makefile.format 2008-02-27 14:11:27.000000000 +0100 -+++ dvd+rw-tools-7.1/Makefile 2012-08-23 17:30:20.037822589 +0200 -@@ -22,6 +22,7 @@ pkg: - $(DIST)/Makefile.m4 \ - $(DIST)/dvd+rw-tools.spec \ - $(DIST)/growisofs.1 \ -+ $(DIST)/dvd+rw-format.1 \ - $(DIST)/transport.hxx \ - $(DIST)/mp.h \ - $(DIST)/win32err.h \ -diff -up dvd+rw-tools-7.1/Makefile.m4.format dvd+rw-tools-7.1/Makefile.m4 ---- dvd+rw-tools-7.1/Makefile.m4.format 2012-08-23 17:30:19.971822000 +0200 -+++ dvd+rw-tools-7.1/Makefile.m4 2012-08-23 17:30:20.038822597 +0200 -@@ -32,6 +32,7 @@ BIN_MODE?=0755 - install: dvd+rw-tools - install -o root -m $(BIN_MODE) $(CHAIN) /usr/bin - install -o root -m 0644 growisofs.1 /usr/share/man/man1 -+ install -o root -m 0644 dvd+rw-format.1 /usr/share/man/man1 - ]) - - ifelse(OS,MINGW32,[ -@@ -68,6 +69,7 @@ BIN_MODE?=04755 - install: dvd+rw-tools - install -o root -m $(BIN_MODE) $(CHAIN) /usr/local/bin - install -o root -m 0644 growisofs.1 /usr/local/man/man1 -+ install -o root -m 0644 dvd+rw-format.1 /usr/local/man/man1 - ]) - - ifelse(OS,SunOS,[ -@@ -103,6 +105,7 @@ LDLIBS=-lvolmgt -lrt -lpthread -ldl - install: dvd+rw-tools - /usr/ucb/install -o root -m 04755 $(CHAIN) /usr/local/bin - /usr/ucb/install -o root -m 0644 growisofs.1 /usr/local/man/man1 -+ /usr/ucb/install -o root -m 0644 dvd+rw-format.1 /usr/local/man/man1 - ]) - - ifelse(OS,HP-UX,[ -@@ -141,6 +144,7 @@ LDLIBS=-lrt -lpthread - install: dvd+rw-tools - /usr/sbin/install -o -f /usr/local/bin $(CHAIN) - /usr/sbin/install -o -f /usr/local/man/man1 growisofs.1 -+ /usr/sbin/install -o -f /usr/local/man/man1 dvd+rw-format.1 - ]) - - ifelse(OS,IRIX,[ -@@ -178,6 +182,7 @@ BIN_MODE=04755 # set-root-uid - install: dvd+rw-tools - /sbin/install -u root -m $(BIN_MODE) $(CHAIN) /usr/local/bin - /sbin/install -u root -m 0644 growisofs.1 /usr/local/man/man1 -+ /sbin/install -u root -m 0644 dvd+rw-format.1 /usr/local/man/man1 - ]) - - ifelse(OS,Linux,[ -@@ -202,6 +207,7 @@ install: dvd+rw-tools - install $(minus_o) -m $(bin_mode) $(CHAIN) $(prefix)/bin - [[ -d $(mandir)/man1 ]] || mkdir -p $(mandir)/man1 - install $(minus_o) -m 0644 growisofs.1 $(mandir)/man1 -+ install $(minus_o) -m 0644 dvd+rw-format.1 $(mandir)/man1 - -[[ -f rpl8 ]] && install $(minus_o) -m $(bin_mode) rpl8 $(prefix)/bin || : - -[[ -f btcflash ]] && install $(minus_o) -m $(bin_mode) btcflash $(prefix)/bin || : - ]) diff --git a/dvd+rw-tools-7.1-lastshort.patch b/dvd+rw-tools-7.1-lastshort.patch deleted file mode 100644 index da225d4..0000000 --- a/dvd+rw-tools-7.1-lastshort.patch +++ /dev/null @@ -1,12 +0,0 @@ -diff -up dvd+rw-tools-7.1/growisofs_mmc.cpp.lastshort dvd+rw-tools-7.1/growisofs_mmc.cpp ---- dvd+rw-tools-7.1/growisofs_mmc.cpp.lastshort 2012-04-13 18:09:31.047641524 +0200 -+++ dvd+rw-tools-7.1/growisofs_mmc.cpp 2012-04-13 18:09:34.451763587 +0200 -@@ -540,7 +540,7 @@ ssize_t poor_mans_pwrite64 (int fd,const - // own higher HZ value and disrespects the user-land one. - // Sending them down as milliseconds is just safer... - // -- if (!(errcode=cmd.transport (WRITE,(void *)buff,size))) -+ if (!(errcode=cmd.transport (WRITE,(void *)buff,nbl*2048))) - break; - - //--- WRITE failed ---// diff --git a/dvd+rw-tools-7.1-noevent.patch b/dvd+rw-tools-7.1-noevent.patch deleted file mode 100644 index 19c8c66..0000000 --- a/dvd+rw-tools-7.1-noevent.patch +++ /dev/null @@ -1,19 +0,0 @@ -diff -up dvd+rw-tools-7.1/transport.hxx.debug dvd+rw-tools-7.1/transport.hxx ---- dvd+rw-tools-7.1/transport.hxx.debug 2012-03-07 10:55:07.167322839 +0100 -+++ dvd+rw-tools-7.1/transport.hxx 2012-03-07 15:44:34.384202747 +0100 -@@ -1795,9 +1795,12 @@ static int handle_events (Scsi_Command & - break; - case 5: ret |= 1<<5; break; // Multiple Initiators - case 6: // Device Busy -- if ((event[4]&0xF)==1 && // Timeout occured -- (event[5]&0x3)!=0) -- { poll(NULL,0,(descr&0xFFFF)*100+100); -+ if ((event[4]&0xF)==1) // Timeout occured -+ { -+ if ((event[5]&0x3)==0) // No Event -+ return 0; // Ready to accept any command -+ -+ poll(NULL,0,(descr&0xFFFF)*100+100); - cmd[0] = 0; // TEST UNIT READY - cmd[5] = 0; - if ((err=cmd.transport())) diff --git a/dvd+rw-tools-7.1-sysmacro-inc.patch b/dvd+rw-tools-7.1-sysmacro-inc.patch deleted file mode 100644 index 672258e..0000000 --- a/dvd+rw-tools-7.1-sysmacro-inc.patch +++ /dev/null @@ -1,10 +0,0 @@ ---- dvd+rw-tools-7.1/growisofs.c.orig 2018-07-09 17:13:37.119250266 +0100 -+++ dvd+rw-tools-7.1/growisofs.c 2018-07-09 17:14:25.808251710 +0100 -@@ -439,6 +439,7 @@ - #include - #include - #include -+#include - #include - #include - #include diff --git a/dvd+rw-tools.spec b/dvd+rw-tools.spec deleted file mode 100644 index 3eca3ff..0000000 --- a/dvd+rw-tools.spec +++ /dev/null @@ -1,222 +0,0 @@ -Name: dvd+rw-tools -Version: 7.1 -Release: 35%{?dist} -Summary: Toolchain to master DVD+RW/+R media -License: GPLv2 -URL: http://fy.chalmers.se/~appro/linux/DVD+RW/ - -Source: http://fy.chalmers.se/~appro/linux/DVD+RW/tools/dvd+rw-tools-%{version}.tar.gz -Source1: index.html -Patch1: dvd+rw-tools-7.0.manpatch -Patch2: dvd+rw-tools-7.0-wexit.patch -Patch3: dvd+rw-tools-7.0-glibc2.6.90.patch -Patch4: dvd+rw-tools-7.0-reload.patch -Patch5: dvd+rw-tools-7.0-wctomb.patch -Patch6: dvd+rw-tools-7.0-dvddl.patch -Patch7: dvd+rw-tools-7.1-noevent.patch -Patch8: dvd+rw-tools-7.1-lastshort.patch -Patch9: dvd+rw-tools-7.1-format.patch -Patch10: dvd+rw-tools-7.1-bluray_srm+pow.patch -Patch11: dvd+rw-tools-7.1-bluray_pow_freespace.patch -Patch12: dvd+rw-tools-7.1-sysmacro-inc.patch - -Requires: genisoimage -BuildRequires: gcc gcc-c++ -BuildRequires: kernel-headers m4 -BuildRequires: make - -%description -Collection of tools to master DVD+RW/+R media. For further -information see http://fy.chalmers.se/~appro/linux/DVD+RW/. - -%prep -%setup -q -%patch1 -p1 -b .manpatch -%patch2 -p1 -b .wexit -%patch3 -p1 -b .glibc2.6.90 -%patch4 -p1 -b .reload -%patch5 -p0 -b .wctomb -%patch6 -p0 -b .dvddl -%patch7 -p1 -b .noevent -%patch8 -p1 -b .lastshort -%patch9 -p1 -b .format -%patch10 -p1 -b .pow -%patch11 -p1 -b .freespace -%patch12 -p1 -b .sysmacro - -install -m 644 %{SOURCE1} index.html - -%build -export CFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing" -export CXXFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing" -export LDFLAGS="$RPM_LD_FLAGS" -make WARN="-DDEFAULT_BUF_SIZE_MB=16 -DRLIMIT_MEMLOCK" %{?_smp_mflags} - -%install -# make install DESTDIR= does not work here -%makeinstall - -%files -%license LICENSE -%doc index.html -%{_bindir}/* -%{_mandir}/man1/*.1* - -%changelog -* Fri Apr 16 2021 Brian Stinson - 7.1-35 -- Rebuilt for RHEL 9 BETA on Apr 15th 2021. Related: rhbz#1947937 - -* Tue Jan 26 2021 Fedora Release Engineering - 7.1-34 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild - -* Mon Jul 27 2020 Fedora Release Engineering - 7.1-33 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild - -* Tue Jan 28 2020 Fedora Release Engineering - 7.1-32 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild - -* Wed Jul 24 2019 Fedora Release Engineering - 7.1-31 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild - -* Thu Jan 31 2019 Fedora Release Engineering - 7.1-30 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild - -* Thu Jul 12 2018 Fedora Release Engineering - 7.1-29 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild - -* Mon Jul 9 2018 Peter Robinson 7.1-28 -- Fix version check - -* Mon Jul 9 2018 Peter Robinson 7.1-27 -- Package cleanups, add patch to fix FTBFS, use %%license - -* Fri Feb 23 2018 Florian Weimer - 7.1-26 -- Use LDFLAGS from redhat-rpm-config - -* Wed Feb 07 2018 Fedora Release Engineering - 7.1-25 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild - -* Wed Aug 02 2017 Fedora Release Engineering - 7.1-24 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild - -* Wed Jul 26 2017 Fedora Release Engineering - 7.1-23 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild - -* Fri Feb 10 2017 Fedora Release Engineering - 7.1-22 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild - -* Wed Feb 03 2016 Fedora Release Engineering - 7.1-21 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild - -* Fri Oct 09 2015 Frantisek Kluknavsky - 7.1-20 -- serious typo in spec file - patch10 applied twice, patch11 not at all - -* Wed Jun 17 2015 Fedora Release Engineering - 7.1-19 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild - -* Sat May 02 2015 Kalev Lember - 7.1-18 -- Rebuilt for GCC 5 C++11 ABI change - -* Fri Nov 14 2014 Frantisek Kluknavsky - 7.1-17 -- added dvd+rw-tools-7.1-bluray_pow_freespace.patch, - based on https://bugzilla.redhat.com/show_bug.cgi?id=1082360 - count nwa (next writeable address) even in pow (pseudo overwrite) mode - -* Sat Aug 16 2014 Fedora Release Engineering - 7.1-16 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild - -* Sat Jun 07 2014 Fedora Release Engineering - 7.1-15 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild - -* Sat Aug 03 2013 Fedora Release Engineering - 7.1-14 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild - -* Mon Jun 24 2013 Frantisek Kluknavsky - 7.1-13 -- when formating blu-ray as srm+pow, handle it later correctly as srm+pow, not srm -(credits Thomas Schmitt) - -* Wed Feb 13 2013 Fedora Release Engineering - 7.1-12 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild - -* Mon Aug 27 2012 Honza Horak - 7.1-11 -- Spec file cleanup -- Print error in case we want to write already written DVD-RW in Sequential - Recording mode (bug #810838) -- Add man page for dvd+rw-format - -* Wed Jul 18 2012 Fedora Release Engineering - 7.1-10 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild - -* Mon Apr 16 2012 Honza Horak - 7.1-9 -- Allow buffer length of the block to be shorter than multiple of 16, - even in case of DAO writing (replaces the previous fix) - Resolves: #810483 - -* Fri Apr 06 2012 Honza Horak - 7.1-8 -- Align blocks count to multiple of 16 also in case of DAO writing - Resolves: #810483 - -* Wed Mar 07 2012 Honza Horak - 7.1-7 -- applied patch from Petr Sumbera to handle Teac DVD drive timeout issue - Resolves: #799299 - -* Fri Jan 13 2012 Fedora Release Engineering - 7.1-6 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild - -* Wed Jun 23 2010 Roman Rakus - 7.1-5 -- Compile with -fno-strict-aliasing CFLAG - -* Fri Jul 24 2009 Fedora Release Engineering - 7.1-4 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild - -* Tue Feb 24 2009 Fedora Release Engineering - 7.1-3 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild - -* Wed Dec 17 2008 Roman Rakus - 7.1-2 -- Allow burn small images on dvd-dl - Resolves: #476154 - -* Fri Aug 15 2008 Roman Rakus - 7.1-1 -- new version 7.1 - -* Wed Mar 26 2008 Harald Hoyer 7.0-11 -- fixed widechar overflow (bug #426068) (patch from Jonathan Kamens) - -* Mon Feb 18 2008 Fedora Release Engineering - 7.0-9 -- Autorebuild for GCC 4.3 - -* Tue Nov 20 2007 Harald Hoyer - 7.0-8 -- added a patch to fix a reload problem on some drives, - after a successful burn - -* Fri Aug 31 2007 Matthias Saou 7.0-7 -- Minor spec file cleanups (tabs vs. spaces, etc.). -- Use install instead of cp for the html file to avoid umask differences. - -* Fri Aug 17 2007 Harald Hoyer - 7.0-6 -- changed license to GPLv2 - -* Wed Aug 15 2007 Harald Hoyer - 7.0-5 -- added limits.h to transport.hxx - -* Thu Jun 21 2007 Harald Hoyer - 7.0-4 -- fixed exit status (#243036) -- Allow session to cross 4GB boundary regardless of medium type. - Add a -F option (used instead of -M or -Z), which displays - next_session offset and capacity. (#237967) - -* Tue Feb 27 2007 Harald Hoyer - 7.0-3 -- fixed specfile issues (#209985) - -* Thu Dec 14 2006 Harald Hoyer - 7.0-0.4 -- set pthread stack size according to limit (#215818) - -* Wed Dec 13 2006 Harald Hoyer - 7.0-0.3 -- use _SC_PHYS_PAGES instead of _SC_AVPHYS_PAGES to determine available memory -- Resolves: rhbz#216794 - -* Fri Nov 03 2006 Harald Hoyer - 7.0-0.2 -- define RLIMIT_MEMLOCK, which should resolve the memlock problems - -* Thu Oct 26 2006 Harald Hoyer - 7.0-0.1 -- new version 7.0 diff --git a/index.html b/index.html deleted file mode 100644 index 1e39c4e..0000000 --- a/index.html +++ /dev/null @@ -1,1295 +0,0 @@ - - - - -Blu-ray Disc/DVD+RW/+R/-R[W] for Linux - - - - - - - - - -

- -
-

Blu-ray Disc/DVD+RW/+R/-R[W] for Linux

-
by <appro@fy.chalmers.se>, -September 2006
-		Japanese -
-

- -

- - - - -
Q. What is this page (not) about?
A.  - Maybe to your disappointment it is not about - video(*). The scope of this page is primarily - computer storage applications of Blu-ray Disc and - DVD±RW/±R, things like backup, archiving, data - exchange... The downloadable files are an optional Linux 2.4 kernel DVD+RW patch and a - couple of user-land utilities dubbed as dvd+rw-tools. - -

- - -
(*) - Though it doesn't mean that you can't burn - DVD-Video discs with dvd+rw-tools. [Unlike Video-CD] DVD-Video - is "molded" in an ordinary data file system and - therefore no explicit support by the burning program is - actually required. In other words it is the DVD-Video - content preparation which is beyond the scope of this - page.
-

- -

- - - - -
Q. Kernel patch? This sounds too complicated - already! Can't I just use [vanilla] cdrecord? - -
A. It should be explicitly noted that the user-land - utilities, dvd+rw-tools, do suffice for BD/DVD recording - without explicit kernel support. So if they fulfill your requirements, then - patching the kernel is by all means optional. As - for [vanilla] cdrecord, non-CD recording strategies are - somewhat different, so it simply doesn't work (nor does - dvdrecord with media other than DVD-R[W], despite what RedHat - 7.3 Release Notes say). On additional note Linux kernel - version 2.6>=10 is equipped with packet - writing driver which supports even DVD rewritable media, - but I haven't tested it myself, so don't ask:-)
- -

- - - -
Q. What is the kernel patch good for then? -
A. DVD+RW (but not DVD+R nor any DVD-dash) is a true random - write access media and therefore is suitable for housing of an - arbitrary file system, e.g. udf, vfat, ext2, etc. This, - and this alone, qualifies DVD+RW support for kernel - implementation. However, I have to recommend to - deploy it with caution, see tutorial - for further details. Also note that not all OEMs seem to live - up to the promise of true random write access. As for the - moment of this writing apparenly only 2nd generation - Ricoh-based units (see dvdplusrw.org for - generation listings) equipped with later firmware can sustain - I/O fragmentation (see Technical Ramblings below for further - details) and perform reliably. -
- -

- - - - -
Q. What are the dvd+rw-tools for?
A. As implied/already mentioned - to master the Blu-ray Disc and DVD media, both +RW/+R and - -R[W]. I could simply refer to the - tutorial below, but figured that couple of words about the - [original] design ideas behind growisofs, the principal - burning utility, wouldn't harm. Even though a modified - kernel can let you put for example an ext2 file system on - DVD+RW, it's probably not very practical, because you most - likely want to access the data on an arbitrary computer. - Or in other words you most likely want ISO9660. The trouble is - that you might as well want to add data now and then. - And what options do you have in the lack of multiple sessions - (no, DVD+RW has no notion of multiple sessions)? Complete - re-mastering which takes more and more time as data set grows? - Well, yes, unless you employ growisofs! Growisofs - provides the way to both lay down and grow an ISO9660 - file system on (as well as to burn an arbitrary pre-mastered - image to) all supported optical media.
- -

- - - - -
Q. But if they support both + and - recording - strategies, why are they called dvd+rw-tools?
A. For historical/nostalgical reasons, as originally they did - support exclusively DVD+plus. On the other hand now, when the - vast majority of DVD burners that are being introduced to the - market today are DVD+capable, the name most likely refers to - your unit in either case. And you can always consider the plus - in the name as notion of a unique quality, such as - "seamless" multisessioning, not as reference to some - particular format:-)
- -

- - - - -
Q. Do I still need cdrtools? -
A. Yes. It should be explicitly noted that growisofs is a - front-end to mkisofs, i.e. invokes mkisofs to perform the - actual ISO9660 file system layout. Secondly, the DVD burners - available on the market can burn even CD-R[W] media and - cdrecord is the tool for this job [and this job only].
- - - -

- - - - -
Q. Does it work with my recorder unit? -
A. If your unit is MMC compliant, - then the answer is "most likely it - just does." Well, as the probability of your unit being - non-MMC compliant is virtually zero, the answer in practice is - unconditionally "most likely." - The [core] tools were reported to work with a wide range of - drives, including [but not limited to] HP - dvd[12345]x0i, Ricoh MP512x, Philips - DVDRW[248]xx, SONY DRU-[157]x0, NEC - ND-[1234]xx0, TDK indiDVD 4x0N, - Plextor PX-[57]xx, Benq DW[48]00A, - OptoRite DD0[24]0x, Lite-On - LDW-[4816]xxS, as well as nonplus - units such as Pioneer DVR-x0[45679], LG - GxA-40[248]x, Toshiba SD-R[56]112, - Panasonic UJ-811, LF-D[35]1x, and not - the least all-mighty - SW-5582...
- -

- - - - -
Q. Is there a GUI front-end available for - dvd+rw-tools? -
A. K3b, version 0.10 - and later, and nautilus-cd-burner, - version 0.5.1 and later, are both hiding growisofs behind their - pretty buttons and menus:-) Keep in mind that those are not - directly related to dvd+rw-tools development - effort and GUI users should turn elsewhere for end-user - support. Oh! dvd+rw-tools 5.10.x is a minimum requirement for - GUI frontends...
- -

- - - - -
Q. I don't run Linux. What are my options? -
A. Version 5.4 adds support for OpenBSD/NetBSD. - Version 5.6 adds support for Solaris 2.x [commercial licensing - terms for distribution on Solaris are to be settled with Inserve Technology]. - Version 5.8 features FreeBSD - port contributed by Matthew Dillon, FreeBSD Development Team - alumnus. Hewlett-Packard Company has donated - HP-UX 11 support for - 5.14(*). IRIX 6.x support appears in - 5.19, Win32 one - in 6.0, - while Mac OS X - in 7.0... - -

- - - - - - -
¡ - Common usage tip! Whenever - separately available [and unless stated otherwise], do use - character-type device entry with dvd+rw-tools, - e.g. OpenBSD/NetBSD users should stick to /dev/rcdXc.
(*) - As of 5.14 HP-UX support was classified as - "initial." Version 5.18 in turn is the one which has - undergone HP quality assurance testing - and is delivered on HP - software depot.
-

- -

- -

Foreword

- -

As of May 2003 I've decided to advise users to -turn to <cdwrite@other.debian.org> -on support matters. It's an open list, meaning that you don't have -to be subscribed to post -a problem report. List archives can be found at both subscribe page and mail-archive.com. -When submitting report, provide versioning information, exact -command line, exact output generated by the program and -complement it with dvd+rw-mediainfo output for -resulting recording. Do check couple of last archived months, as the -issue might have been discussed recently. If you've chosen to -contact me personally and haven't heard back within a week or so, then -you most likely overlooked something on this page. Please read it more -attentively... - -

Special thanks for hardware donations [in -chronological order]:
- -  - -  - -  - -comm*tech  - -

- -

Tutorial

- -

- -
    - -

  • If your burner unit is managed by some -Linux(*) removable media -automounting/autoplaying facility, such as autofs, supermount, -subfs/submount, magicdev, autorun or similar, take it out of its -control! I can't help you with the latter, check your system -documentation (such as google perhaps:-) for specific instructions. -Failure to take your unit out of -Linux(*) automounting/autoplaying facility -control can result in busted recording, a coaster! At the -very least you have to make sure your unit is not automounted during -recordings. - - - - -
    (*) -dvd+rw-tools support Solaris volume manager and -IRIX mediad in more gracious manner and it's safe to leave recorder -under their control.
    - -

  • Remember to consult Hardware Compatibility Notes for possible -caveats or vendor-specific instructions for your unit. Well, such -reminder belongs at the end of tutorial, but I consider it important -enough to bring it up already here:-) - -

  • If you have an IDE unit and run 2.4.x -kernel, you most likely want to "route" it through ide-scsi -emulation layer by either: - -

      -
    • passing "hdX=ide-scsi" -argument to kernel; -
    • appending following lines to your /etc/modules.conf: -
      -
      options ide-cd ignore=hdX
-pre-install sg modprobe ide-scsi
-pre-install sr_mod modprobe ide-scsi
-pre-install ide-scsi modprobe ide-cd
-
      -
    - -

    Keep in mind that once hdX -is routed through ide-scsi, you can no longer refer to /dev/hdX(*), but to corresponding -/dev/scdN only. - -

    - - -
    (*) -well, except as in hdparm -d [0|1] /dev/hdX. As for DMA settings. Several users of -NEC[-based] units have reported that their systems crash during DVD -recording. The problem appears to be related to DMA settings, at least -switching it off reportedly helps. The problem appears to be specific to -some IDE chipsets... -
    - -

  • If you have an external unit, just get -it working as CD-ROM first. I myself have no personal experience -whatsoever with USB or IEEE1394/Firewire optical storage -devices and have to direct you elsewhere for specific instructions. I -however am confident that if you manage to get your drive working -reliably as CD-ROM and CD-R[W] -burner, then you won't have any troubles with dvd+rw-tools either. USB -connected drives were reported to be working fine since eternity. -Firewire connected drives in turn were reported to fail miserably under -2.4.18. The failure didn't seem to be DVD recording related as it -reportedly failed burning even CD-R media. Firewire support was -substantially revamped in 2.4.19, and dvd+rw-tools were reported to -work with this and later kernels. - -

  • If you're running 2.4.19 or .20, consider -applying this drivers/scsi/sg.c patch. -The bug is fixed in .21. I write "consider" and not -"do" for the following reasons: - -

      -
    • dvd+rw-tools are not affected by this bug (as they don't use SG_IO -interface), cdrecord [potentially] is; -
    • I however haven't actually experienced the problem with cdrecord -(maybe yet, kernel could have managed to keep buffers neatly aligned -while talking to cdrecord those times I tried), it was VMware that has -failed miserably on me; -
    - -

    As of version 5.6 dvd+rw-tools add support for SG_IO -pass-through or in other words support for Linux 2>=5[.43], -where "generic" SCSI interface can be bypassed by issuing -SG_IO ioctl directly against block device, such as /dev/hdX. I wish it worked without need for interim -patches #1 and #2, (the latter is relative to -2.5.69-75, the 1st problem is addressed in .71, 2nd one - .75-bk3 in -"last -minute" prior first 2.6 cut. As for 2.6 in more general sense. -As you can imagine this new interface renders ide-scsi layer -superfluous and "the[ir] official plan™" is to scrap -it. I'm not really fond of the idea, but not for /dev/sg* account. I -mean I [personally] would prefer to keep ide-scsi and use SG_IO -pass-through with /dev/scdN, rather than with -/dev/hdX:-) - -

    If you have to make dvd+rw-tools work under Linux -kernel 2.6.8, then upgrade the tool-chain to 5.21.x or later and -manually reward the installed binaries with set-root-uid flag. But the -"supported" recommendation is to just stay away from this -particular kernel version. As for 2.6>8, dvd+rw-tools 5.21.x is -requirement. Oh! dvd+rw-booktype utility would require set-root-uid -privilege then. Given its semi-official status and the fact that this -utility works only with limited number of units, installation procedure -abstains from installing dvd+rw-booktype set-root-uid, leaving -this security sensitive choice to the end-user. - -

  • Download, unpack and compile the the tool-chain. To build the thing do pick the -.tar.gz archive, which contains Makefile as well as .spec file. You -will need both C and C++ compilers installed. Separate -source code files found in the download catalog -are provided mainly for on-line reference purposes (such as revision history:-). - -

    If your Linux kernel supports multiple ABIs (e.g. -Linux-sparc64 can run even 32-bit Linux-sparc applications, as well as -Linux-x86_64 can execute legacy 32-bit i386 binaries), make sure you -compile for native 64-bit ABI (which can normally be done with -'make TARGET_ARCH=-m64'). The problem here is that 64-bit -kernel has to explicitly convert ioctl structures passed by 32-bit -applications and apparently it does really lousy job when it comes to -CDROM_SEND_PACKET ioctl deployed by dvd+rw-tools. - -

  • As new media products and brands are being -introduced to the market all the time, it apparently pays off to -periodically check for firmware updates. For elder units -firmware update might even be an absolute requirement for using -new media. Special note for HP users. HP no longer posts firmware -updates on a web-page. Instead they let some Windows auto-update gizmo -to pick firmware updates among dvd[1-6]00*.exe -files in their FTP -directory, so that readers of this page tend to miss them... - -

  • Formatting the BD and DVD+RW media. -Virgin BD and DVD+RW media needs to be initally formatted prior usage. -Once again, only virgin BD and DVD+RW media needs to be -formatted. As of version 5.10 growisofs detects blanks and applies -initial formatting procedure automatically. Otherwise same effect can -be achieved by passing the device name, e.g. /dev/scd0, as an -argument to dvd+rw-format. Well, -in BD case it does offer more flexibility than -growisofs. To make formatting process reasonably fast, less than 1 -minute, the media gets formatted only partially, as you can notice by -observing progress indicator displayed by dvd+rw-format. The final -indicator value varies from firmware to firmware, values as low as 1.6% -were observed. But it does not mean that you can only write that -little. The unit keeps formatting transparently, as you add more -data. Oh! Do keep in mind that DVD capacity of 4.7GB is expressed in -salesman's GB, i.e. 10003 and not 10243. And -so is one of BD. - -

    It was observed that excessive reformats can render -DVD+RW media unusable already after 10-20 reformats. It appears to be a -firmware deficiency, not some common media defect [at least it was -perfectly possible to salvage the media in a unit of different brand], -but I don't recommend [enforced] reformat in either case. - -

    Note that re-formatting procedure does not -substitute for blanking. If you want to nullify the media, e.g. for -privacy reasons, do it explicitly with 'growisofs -Z -/dev/scdN=/dev/zero'. Otherwise just -write over previous recording as it simply wasn't there, no -re-formatting is required. - - - -

  • Burning with growisofs. There is hardly a need for -manual for growisofs. In a nutshell growisofs just passes all command -line arguments to mkisofs and dumps its output directly onto the media. -The first part means that you basically can [well, should] -consult mkisofs manual page and -accompanying reference documentation (including multisession related -section[s]) and the second part means that you shouldn't expect an -ISO-image on the standard output (nor make sure you have enough free -temporary storage:-). Differences from mkisofs command line -are: - -

      -
    • you may not use -o option; -
    • you don't have to specify -C option, growisofs will construct one -for you; -
    • there is internal -Z option for initial session recording, this -substitutes for originally suggested 'mkisofs | dd of=/dev/scd0'; -
    - -

    Otherwise everything that applies to -[multisession] mastering with mkisofs applies to growisofs as well. For -example just like with mkisofs you should make a note on which options -you used to master the initial "session" with and stick to -them, e.g.: - -

    -growisofs -Z /dev/scd0 -R -J /some/files
-growisofs -M /dev/scd0 -R -J /more/files
-
    - -

    Oh! Do make sure you have at least mkisofs 1.14 on your $PATH (mkisofs 1.14 is part of cdrtools -1.10). If you consider passing /same/files as argument, or in -other words consider deploying growisofs for incremental -multisession backups, then you shall find this '-old-root' extension to -mkisofs 2.0-2.01 simply indispensable. -The idea and implementation by Patrick Ohly is to -"graft" recording sessions as separate directories. Each -backup increment/directory is ment to contain both updated files and -references to previously backed up ones, which facilitates -comparison between increments as well as fine-graded restore. - -

    Number of users asked about opposite to -multisessioning: multivolume support. Being essentially a recording -program growisofs does not support multiple volumes by itself. There're -couple of front-ends I can recommend that arrange for this: scdbackup and -shunt. But back to -growisofs... - -

    In addition to intuitive -Z interpretation, -growisofs [version 3.3 and later] recognizes special form of -Z command -line option which permits burning of arbitrary pre-mastered images. The -"magic" command is: - -

    -growisofs -Z /dev/scd0=image.iso
-
    - -

    where image.iso represents an arbitrary -object in the file system, such as file, named pipe or device -entry. No, nothing is "growing" here and command name is -counter-intuitive in this particular context. And here is even less -intuitive:-) If you wish to burn down output generated by an -arbitrary program, you can use: - -

    -dumpsomething | growisofs -Z /dev/scd0=/dev/fd/0
-
    - -

    Burning BD-R/DVD±R implies extra limitations: - -

      - -
    • Needless to say that you have only one shot with -Z -option:-) - - - -
    • Unlike DVD+RW, DVD±R media does have notion of multiple -sessions. However! Not all legacy units can "see" -beyond the first one. Few DVD-ROM units are capable of DVD-R -multiborder playback, even fewer support DVD+R multisessioning. In -other words your DVD burner might be the only unit in your vicinity -capable to access data added at different occasions. - -
    • Even if your DVD unit does "sense" multiple sessions, -Linux kernel [2.4] sometimes fails to pull that information from the -drive:-( Till the problem is looked into and resolved you can -work it around by reloading corresponding driver, most likely -'rmmod sr_mod'. - -
    • Linux kernel 2.6<10 -users might experience problems -mounting multisession media with last session starting beyond -2.2GB boundary. As fast-acting remedy I can suggest to route your unit -through ide-scsi, the way it was under 2.4. Even though it's declared -unsupported it actually still works in 2.6 (I for one still use it). - -
    • If you go for BD-R/DVD±R multisessioning, you have to use -mkisofs from cdrtools-2.0 -or later or apply this patch. - -
    • And when it comes to DVD+R Double Layer and DVD-R -Dual Layer recordings, growisofs applies yet another limitation, -purely artificial. Taking into consideration Double Layer media prices -growisofs is programmed to refuse to perform unappendable -recordings which are less than 1/2 of blank capacity and to advice -to use single layer media instead. - -
    • DVD-R Dual Layer multisessioning is not supported for a reason -discussed on the -RW companion page. Once -again, as of the moment of this writing DVD-R Dual Layer -recordings come out unappendable and can not be grown. -
    - - -

    And once again, do keep in mind that 4.7GB are -salesman's GB, i.e. 10003 and not 10243. If -translated to "real" GB, single layer -DVD±R[W] capacity is not larger than 4.4GiB, and BD -- not larger than 23.3GiB! It should also be noted that earlier -growisofs versions did not check if there is enough space on media to -accommodate the data set to be burned, meaning that it was your sole -responsibility to make sure "overburn" condition is not -raised. As of version 5.2 growisofs performs the necessary checks -for you and refuses to start recording if "overburn" -condition appears to be unavoidable. This behaviour can be overridden -with -overburn command-line option. - -

  • If you're satisfied with growisofs, then you -should just proceed to the next chapter -and abstain from applying the optional 2.4.x kernel patch. If -you haven't stopped reading beyond this line, download the patch, apply it, rebuild the -kernel or modules and re-install (kernel or cdrom.o and sr_mod.o -modules, whichever appropriate), but don't ask me how. As you could -have noticed, patch targets SCSI CD-ROM module. This means that you -have to "route" your IDE unit through ide-scsi to get this one -working. To see it in action, insert formatted DVD+RW media and try to -access it, 'dd if=/dev/scdN count=0' -would do. Then verify that kernel logs "srN: mmc-3 profile: 1Ah". You should now be -able to 'mkisofs -pad . | dd of=/dev/scdN -obs=32k' or even 'mke2fs -b 2048 /dev/scdN' and observe kernel logging "srN: dirty DVD+RW media." - - - -

    Linux 2.6 DVD+RW kernel support is planned in -line with DVD+MRW kernel support. This [unfortunately] means that -industry has to deliver a DVD+MRW capable unit first. Yes, the last -sentence means that despite all the promises, there are no such units -available on the market yet. As of the 1st of August 2003, Ricoh MP5240A, -Philips DVDRW416K or BenQ DW400A do not actually implement -Mt.Rainier/EasyWrite support. It remains to be seen if they will offer -it in form of firmware upgrade. In either case, the [original] project -goal is not only read-write support for DVD+[M]RW capable units -themselves, but even playback of DVD+MRW formatted media in legacy -DVD-ROM units (when defect list will be read and interpreted by OS -software in opposite to Mt.Rainier firmware). - -

  • Even though kernel now -permits to build and mount arbitrary file system, there is one thing you -must keep in mind before you just proceed, no matter how -tempting it might appear. - -

    As you might know DVD+RW media can sustain only -around 1000 overwrites. The thing about fully fledged file systems -is that every read [or tight bunch of 'em] is accompanied by -corresponding i-node update or in other words a write! Now, let's say -you lookup the mount point (e.g. ls /mnt/dvd) ten times a day. This -gives you a 100 days lifetime on your mountpoint and therefore media. -Not really much, huh? So do use noatime mount option with -DVD+RW media or have it mounted read-only most of the time. However! -Every read-write mount "costs" a super-block update. So that -if you remount the media say 3 times a day, it would last for about a -year [supermount -would exhaust the "budget" way sooner]... Defect management -[in firmware, a.k.a. Mt.Rainier, -or at file system level] would improve the situation, but ideally -file system driver should definitely refrain from modifying the -super-block [marking it dirty] if nothing was actually written since -last mount. Given the development status of Linux UDF the -chances for seeing the latter implemented [for UDF] are more than just -conceivable. The request is already filed and even possible solution is -being discussed. But why not give UDF a shot already then? By default -UDF write support is unfortunately disabled and you might have to -reconfigure the kernel and rebuild modules. Alternatively [my preferred -option actually] fetch the code at SourceForge and -build the module separately. Of course you will have to fetch and build -udftools as well. But once it's done just type: - -

    -mkudffs --spartable=2 --media-type=cdrw /dev/scdN
-mount -o rw,noatime /dev/scdN /mnt/cdrom
-
    - -

    mkudffs command line options were suggested -by UDF maintainer, Ben Fennema. - -

  • Performance optimization. This paragraph -applies only if you've patched the kernel. As some of you might -remember the original recommendation was "do use obs=32k -for optimal performance." Well, it was rather naive of me to say -so, as common block device layer completely reorganizes the -stream so that '>/dev/scd0' is as good as '|dd -of=/dev/scd0 obs=32k'. It should also be noted that dumping to -/dev/scd0 puts quite a pressure on VM subsystem, as the data passes -through block buffer cache. To minimize the pressure and improve -overall system performance bind the cdrom device to a raw device, e.g. -'raw /dev/raw/raw1 /dev/scd0', growisofs will locate and use -it automatically. obs=32k makes perfect sense with /dev/raw devices, -but dd (as well as most other programs, e.g. tar) won't work as -/dev/raw expects specifically aligned buffer... As temporary -workaround, just to get you going so that you can start figuring things -out, consider this -"hacklet"... - -

- -

 - -

Compatibility: caveat lector

- -

- -

This paragraph discusses "DVD-ROM -compatibility," or playability of already recorded media in legacy -units. Blank media compatibility issues, or cases such as failure to -start or fulfill recording because of poor media support by burner -firmware, are beyond the current scope. Turn to your vendor for list of -supported media and/or to the public to share your -experience. - -

In order to optimize seek times DVD[-ROM] players -calibrate their mechanics every time the media is loaded by sliding -the optical head some place, picking up the signal and noting the -physical block address underneath the lens. In order for this procedure -to work with re-writable/recordable media, that particular spot has to -be written to [or de-iced in DVD+RW terms]. Some units slide the head to -30mm [radial] to calibrate, some to 35mm. In order to keep such players -"happy," make sure that at least 1GB is written [before you -attempt to mount it in DVD-ROM unit]. - -

Other units attempt to seek to lead-out [or vicinity -of it] for calibration purposes. Now the catch is that it's perfectly -possible to produce a DVD+RW disc without lead-out. Most notably media -initially formatted with dvd+rw-format [apparently] -doesn't have any lead-out, not to mention that practically whole -surface remains virgin. If you fail to mount/play DVD+RW media, attempt -to - -

dvd+rw-format -lead-out /dev/scdN
- -

which relocates the lead-out next to outermost -written sector as well as makes sure there is no virgin surface before -it. Previously written data is not affected by this operation. - - -

Then non-finalized DVD+R and Sequential -DVD-R[W] discs don't have lead-out either(*). -If you fail to mount/play DVD+R media and wish to sacrifice the -remaining space for immediate compatibility, just fill the media -up(**). Alternatively if you master volume in a single take -and don't plan to use it for multisessioning(***), you have -the option to invoke growisofs with -dvd-compat option and cut -the real lead-out directly after the first session. - -

- - - - - - - - - -
(*) -Well, there are lead-outs at the session edges, but -the problem is that "End Physical Sector Number of Data Area" -field in "Control Data Zone" of the lead-in contains address -of the largest media sector, which makes affected DVD[-ROM] players -calibrate at the outermost edge instead of the first session. Actually -I fail to understand why don't they burn the address of last sector of -the first session in the lead-in even on multisession discs... -
(**) -But beware the 4GB limit! -If 4GB is already an issue, or if you don't feel like throwing -unrelated data on the media in question, then invoke 'growisofs --M /dev/scd0=/dev/zero' (supported by 5.6 and later). -Alternative is to re-master the whole volume, naturally with --dvd-compat option. -
(***) -E.g. when mastering DVD-Video disc:-) Note that --dvd-video option [passed to mkisofs] engages --dvd-compat automatically.
- -

- -

Then we have logical format compatibility -issue(s). Probably the very ground for all the controversy around -DVD+RW, rather around DVD+RW media not being playable in a whole range -of players. DVD+RW Alliance was keen to blame on DVD-ROM vendors, even -claiming that they deliberately block playback. But the fact is that -format specifications don't explicitly say that unrecognized format -[designated by "Book Type" field in "Control Data -Zone" of the lead-in] should be treated as DVD-ROM -and [in my opinion] it was rather naive of them to claim and expect -that the media will be playable in "virtually all players." -This deficiency was recognized by practically all DVD+RW vendors [well, -apparently by "traditional" DVD+RW vendors and not -"latest generation" vendors such as Sony, NEC, TDK...] and a -secret vendor-specific command -manipulating this "Book Type" field was implemented. So if -you fail to mount/play DVD+RW media, you might have an option to - -

dvd+rw-booktype -dvd-rom -media /dev/scdN
- -

Once again. Not all vendors support this and you -can't expect this utility to work with all recorders. - -

It's naturally not possible to manipulate the -"Book Type" field on DVD+R media, that is not after the -lead-in is written [which takes place at the moment the first session -gets closed]. But it might be possible to control how it [lead-in] is -going to be branded by programming the drive in advance: - -

dvd+rw-booktype -dvd-rom -unit+r /dev/scdN
- -

Meaning that if you fail to play DVD+R media, you -can attempt to burn another disc with more appropriate unit settings. -For more background information about dvd+rw-booktype, see "Compatibility -Bitsettings" article at dvdplusrw.org. - -

There [potentially] are other logical -DVD+RW(*) format incompatibilities, but the "Book -Type" issue discussed above is the only one "officially" -recognized. Well, it's actually understandable as it's the only one -that can be recognized and addressed by a DVD+RW vendor alone. -Recognition of other incompatibilities would require cooperation from -DVD[-ROM] player vendors and that's something they -apparently are not willing to show referring to the fact that DVD+RW -format is not approved [and apparently never will be] by DVD Forum(**). - -

- - - - - -
(*) -Finalized DVD+R media branded with -DVD-ROM "Book Type" is virtually identical to -DVD-ROM.
(**) -To which I say "so what?" DVD Forum is an -alliance of manufacturers just like DVD+RW Alliance is. It [or any -other party for that matter] has no authority to deny a technology -development initiative.
- -

- -

Finally there is a physical incompatibility issue. -They claim that there are optical pick-ups out there not being capable -to decode the track because of low reflectivity of DVD+RW media -surface. I write "they claim," because in the lack of -cooperation from DVD[-ROM] vendors it's not possible to -distinguish physical from logical format incompatibility, which I find -important to tell apart in order to make sure at least logical format -incompatibility issues don't persist over time. It might be as trivial -as following. As you surely know [already], DVD+RW has same -reflectivity as dual-layer DVD-ROM. Now the catch is that -the linear pit density in turn is same as of single-layer one. Meaning -that if player makes assumptions about linear pit density based on -reflectivity, then it won't be able to trace the track... But either -way, there is very little you can do about this one, but to try another -player... - -

- -

Technical Ramblings

- -

- -

- -

As for multisession ISO9660 [DVD] -recordings! Unfortunately, Linux ISOFS implementation had certain -deficiency which limits interoperability of such recordings. In order -to understand it, have a look at sample ISO9660 layout to the right... -Now, the problem is that isofs i-nodes(*) are 32 bits wide -(on a 32-bit Linux) and represent offsets of corresponding directory -entries (light-greens), byte offsets from the beginning of media. This -means that no directory (green areas) may cross 4GB boundary without -being effectively corrupted:-( It should be noted that in -reality it's a bit better than it looks on the picture, as mkisofs -collects all the directories in the beginning of any particular session -(there normally are no blues between greens). The first session -is therefore never subject to i-node wrap-around, but not the -subsequent ones! Once again, files -themselves may reside beyond the 4GB -boundary, but not the directories, in -particular not in further sessions. Having noted that directory entries -are actually specified to start at even offsets, I figured that -it's perfectly possible to -"stretch" the limit to 8GB. But in order to assure -maximum interoperability, you should not let any session -start past 4GB minus space required for directory -structures, e.g. if the last session is to fill the media up, it -has to be >400MB. As of version 5.3 growisofs refuses to append -a new session beyond 4GB-40MB limit(**), where 40MB is -pretty much arbitrary chosen large value, large for directory catalogs -that is. Yet it doesn't actually guarantee that you can't suffer -from i-node wrap-around. Interim fs/isofs 2.4 -kernel patch was addressed to those who have actually ran into the -problem and have to salvage the data. Even though permanent solution -for this problem appears in Linux kernel 2.6.8 (thanks to Paul Serice -effort), growisofs keeps checking for this 4GB limit in order to ensure -broader compatibility of final DVD recordings. This check is not -performed for Blu-ray Disc recordings, as probability that a member of -such user community would run something elder than 2.6.9 is considered -diminishingly low. - - - - - - -
(*) -i-node is a number uniquely identifying a single -file in a file system -
(**) -well, as DVD+R Double Layer support was introduced -in 5.20, -use-the-force-luke=4gms option was added to override -this behaviour (naturally recommended for Linux kernel 2.6>=8 users and -kernel developers only;-) -
- -


- -

Why media reload is performed after every -recording with growisofs? Well, it's performed only if you didn't -patch the kernel:-) But no, I do not insist on patching the kernel! -All I'm saying is that in the lack of kernel support, media reload is -performed for the following reasons. In order to optimize file access -kernel maintains so called block cache, so that repetitive requests for -same data are met directly from memory and don't result in multiple -physical I/O. Now the catch is that block cache layer remains totally -unaware of growisofs activities, growisofs bypasses the block -cache. This means that block cache inevitably becomes out of sync, -which in turn might appear to you as corrupted data. Media reload is -performed when flushing the block cache is not an option, e.g. only -privileged user is allowed to perform it. Second reason is to force -kernel to readjust last addressable block in case it was changed as -result of recording. This is done to preclude spurious "attempts to -access beyond end of device." - -


- -

What does [kernel] "DVD+RW support" -really mean? Even though DVD+RW has no notion of [multiple] -sessions, to ensure compatibility with DVD-ROM it's essential to issue -"CLOSE TRACK/SESSION (5Bh)" MMC command to -terminate/suspend background formatting (if any in progress) whenever -you intend to eject the media or simply stop writing and want better -read performance (e.g. remount file system read-only). This is what the -patch is basically about: noting when/if media was written to and -"finalizing" at unlock door. - -

Secondly, whenever you employ fully fledged -file system, I/O requests get inevitably fragmented. -"Fragmented" means following. Even though you can address the -data with 2KB granularity, it [data] is physically laid out in 32KB -chunks. This in turn means that for example writing of 2KB block -involves reading of 32KB chunk, replacing corresponding 2KB and writing -down of modified 32KB chunk. "Fragmented requests" are those -that are smaller than 32KB or/and cross the modulus 32KB boundaries. In -order to optimize the process certain caching algorithm is implemented -in unit's firmware. Obviously it can't adequately meet all possible -situations. And so in such unfortunate situations the drive apparently -stops processing I/O requests returning "COMMAND SEQUENCE ERROR -(2Ch)" ASC. This is the second essential of "DVD+RW -support," namely injecting of "SYNCHRONIZE CACHE (35h)" -MMC command in reply to the error condition in question. The command -flushes the cached buffers which makes it possible to resume the data -flow. - -

Unfortunately the above paragraph doesn't -seem to apply to the 1st generation drives, Ricoh MP5120A and -derivatives:-( "SYNCHRONIZE CACHE (35h)" doesn't -seem to be sufficient and the unit keeps replying with "COMMAND -SEQUENCE ERROR (2Ch)" going into end-less loop. This makes it -impossible to deploy arbitrary file system. I'm open for -suggestions... Meanwhile the I've chosen to simply suspend I/O till the -media is unmounted. Even 2nd gen unit were reported to exhibit similar -[but not the same] behaviour under apparently extremely rare -circumstances. At least I failed to reproduce the problem... The problem -reportedly disappears with firmware upgrade... - -

Then some [most?] of post-2nd gen units, from -most vendors, seem to not bother about complying with -DVD+RW specification, "true random write with 2KB -granularity" part in particular. Instead they apparently expect -host to apply procedure pretty much equivalent to DVD-RW -Restricted Overwrite. To be more specific host seems to be expected to -coalesce 2KB requests and perform aligned writes at native DVD ECC -blocksize, which is 32KB. Formally this should not be required, but -it's the reality of marketplace:-( - -

This one really beats me. Sometimes the unit -simply stops writing signaling a vendor specific positioning error, -03h/15h/82h to be specific. Especially if the media is newly formatted. -Couple of work theories. One is that block buffer cache reorders -requests so that they are not sequential anymore, "FLUSH -CACHE" might do the trick. Another one is that under -"underrun" condition background formatting kicks off and has -to be explicitly stopped. "Underrun" is in quotes because -the unit is supposed to handle temporary data stream outages -gracefully. If you run into this (you most likely will), try to -complement growisofs command line with [undocumented] --poor-man option (which has to be first in the command line). -This option eliminates request reorders and minimizes possibility for -"underrun" condition (by releasing the pressure off VM -subsystem). - -


- -

The original idea was to implement DVD+RW support in -drivers/cdrom/cdrom.c. Unfortunately SCSI layer maintains private -"writeable" flag controlling the ability to issue WRITE -commands. The flag is impossible to reach for from the Unified CD-ROM -driver. But why am I talking about SCSI when there are only IDE units -out there (at least for the time being)? Well, as you most likely want -to occasionally burn even CD-R[W] with cdrecord you want it to go -through ide-scsi emulation layer anyway. So I figured that SCSI CD-ROM -driver is the one to aim for even for DVD+RW. - -

Unfortunately it was not possible to implement it -completely in sr_mod.o:-( Minor drivers/cdrom/cdrom.c -modification was required to sense the media before decision about -whether or not to permit write open. That's because DVD+RW drives are -morphing their behaviour after currently mounted media and it's -essential to identify newly inserted media. - -

Special comment about "what a dirty -hack!!!" To my great surprise it turned out that time-out value you -pass in cdrom_generic_command is simply ignored and time-out is set to -pre-compiled value of 30 seconds. Unfortunately it's way too low for -formatting purposes and I had to do something about it. Alternative to -"the dirty hack" was to add another argument to sr_do_ioctl -and modify all the calls to it... I've chosen to take over those 31 -unused bits from the "quiet" argument instead of modifying -all the calls (too boring). - -

But even if time-out value passed down to kernel -(with either CDROM_SEND_PACKET or SG_IO ioctl) is taken into -consideration, it's apparently not interpreted as user-land code -expects it to. As I figured... There is no documentation on -CDROM_SEND_PACKET, but following the common sense most programmers -(including myself:-) expect it to be interpreted in at least -platform-independent manner, such as milliseconds maybe? SG_IO timeout -in turn is documented -to be measured in milliseconds... Neither of this holds true! Kernel -treats these values as "jiffies," which is a -platform-dependent value representing time elapsed between timer -interrupts. But if we attempt to send down "jiffies," it -might turn out wrong too [at least for the moment of this writing]. The -catch is that [IA-32] kernel developers figured it's cool to shorten -"jiffy," but didn't care to provide user-land with actual -value (well, not of actual interest, too much legacy code to deal with) -nor scale timeouts -accordingly in respect to the legacy value of 10ms. - -

There is another kernel "deficiency" I ran -into while working on the (original version of) dvd+rw-format utility. -The drive provides background formatting progress status, but -unfortunately it's impossible to access it. That's because progress -counter is returned [in reply to "TEST UNIT READY"] as -"NO SENSE/LOGICAL UNIT NOT READY/FORMAT IN PROGRESS" sense -bytes but with "GOOD" status. Apparently any sense data with -"GOOD" status is discarded by the common SCSI layer. - - - -

It was pointed out to me that DVD+RW units work with -Acard SCSI to -IDE bridges. - -

- -

What does plus in DVD+RW/+R -stand for? Originally this paragraph started as following: - -

The key feature of DVD+RW/+R media is -high [spatial] frequency wobbled [pre-]groove with addressing -information modulated into it. This makes it possible to resume -interrupted [or deliberately suspended] burning process with accuracy -high enough for DVD[-ROM] player not to "notice" anything at -playback time. Recovery from buffer underrun condition in DVD-RW/-R -case in turn is way less accurate procedure, and the problem is that -the provided accuracy is very much what average player can tolerate. -Now given that both provided and tolerated inaccuracies are -proportional to respectively writing and reading velocities there -basically no guarantee that DVD-RW/-R recording that suffered from -buffer underrun will be universally playable.

- -

Well, it turned out that I was wrong about one -thing. I failed to recognize that DVD-R[W] -groove also provides for adequately accurate recovery from -buffer underrun condition/lossless linking. Not as accurate as DVD+RW, -but accurate enough for splices to be playable in virtually any -DVD-ROM/-Video unit. Yet! When it comes to DVD-R[W] recording -specificaton apparently insists that you choose between - -

    -
  • buffer underrun protection and -
  • full DVD-ROM/-Video compatibility. -
- -

The specification asserts that the latter is -achieved only in Disc-at-once recording mode and only if data-stream -was maintained uninterrupted throughout whole recording. Once again. -Even though most vendors implement lossless linking in DAO -mode(*), full DVD-ROM/-Video compatibility is -guaranteed only if recording didn't suffer from buffer underruns. The -problem is that "offended" sectors are denoted with certain -linking chunk appearing as degraded user data, few bytes, which -are supposed to be "corrected away" by ECC -procedure(**). DVD+ splices are in turn only few bits large -and are "accounted" to sync patterns, not to user data -area. So that even if suffered from buffer underrun, DVD+ sector is -logically indistiguishable from DVD-ROM. Which is why it's commonly -referred to that DVD+RW/+R combine DVD-ROM/-Video compatibility with -[unconditional] buffer underrun protection. - -

As already mentioned, DVD+ groove has -"addressing information modulated into it," ADIP (ADress In -Pre-groove). This gives you an advantage of writing DVD+RW in truly -arbitrary order, even to virgin surface and practically instantly -(after ~40 seconds long initial format procedure). In addition, DVD+RW -can be conveniently written to with 2KB granularity(***). -DVD-RW in turn can only be overwritten in arbitrary order. -Meaning that it either has to be completely formatted first (it takes -an hour to format 1x media), or initially written to in a sequential -manner. And it should also be noted that block overwrite is -never an option if DVD-RW media was recorded in [compatible] -Disc-at-once or even Incremental mode, only whole disc blanking is. - -

Unlike DVD-R[W], DVD+R[W] recordings can be -suspended at any time without any side effects. Consider following -scenario. You have a lot of data coming in [at lower rate], which is to -be recorded into one file. Meanwhile it turns out that you have to -retrieve previously recorded data. This would naturally require -suspention of recording. Most notably in DVD-R [and naturally DVD-RW -Sequential] case it would result in a hole in the file being recorded. -So called linking area, most commonly 32KB gap, has to be introduced. -So that you either have to wait till the file is complete or figure out -how to deal with holey files. Thanks to ADIP, DVD+R recording is -resumed from the very point it was suspended at. In DVD-RW Restricted -Overwrite case no gaps are introduced, but if the media was formatted -only minimally, suspension/resuming procedure has to be applied and it -takes ~40 seconds to perform one. In DVD+RW case, suspension/resuming -is instant regardless media state. - -

What does all of the above mean in practice? Well, I -was actually hoping that readers would [be able to] figure it out by -themselves. Apparently a couple of "guiding" words are -needed... It means that it's trivial to employ DVD+RW for housing of -live and arbitrary file system, no special modifications to target file -system driver are required... Real-time VBR (Variable Bit Rate) Video -recordings are children's game... - -

Sometimes DVD+RW/+R recording strategy is referred -to as packet writing. I myself am reluctant to call it so (or -TAO/SAO/DAO) for the following reason. Despite the fact that DVD-R[W] -provides for lossless linking (within a packet/extent only), -packets/extents are still denoted with certain linking information -which distinguishes it (recording mode in question) from e.g. -Disc-at-once. Now the point is that written DVD+RW/+R media, rather its -Data Zone, does not contain any linking information and is -logically indistinguishable from one written in DVD-R[W] Disc-at-once -mode (or DVD-ROM for that matter). - -

It's maintained that signal from DVD+ groove (the -one essential for recording, not reading) is much stronger, which makes -it quite resistant to dust, scratches, etc. - -

Now we can also discuss differences between -Double/Dual Layer implementations. DVD+R Double Layer permits for -arbitrary layer break positioning yet maintaining contiguous logical -block addressing. In other words address of the block following the -break is always address of the block preceding one plus 1, even for -arbitrarily positioned break. DVD-R Dual Layer on the -other hand implies unconditionally disjoint logical block addressing -[for arbitrarily positioned layer break that is]. This is because block -addresses as recorded by unit are pre-defined by DVD-dash -groove structure. In practice it means that file system layout has to -effectively have a hole, which "covers" twice the space between chosen -layer break position and outermost edge of the recordable area. And in -even more practical terms this means that mastering programs have to be -explicitly adapted for DVD-R layer break positioning. -Unlike DVD+plus that is. - -

- - - - - - - -
(*) -According to Mt. Fuji draft -buffer underrun protection is not even an option in DVD-R DAO: "If a -buffer under-run occurs, the logical unit shall stop -writing immediately and the logical unit shall start -writing of Lead-out." Protection is defined in Incremental Sequential -mode and DVD-RW context. By the way, note that earlier versions of this -draft also discuss DVD+RW. You should be aware that they refer to -abandoned version which has very little to do with DVD+RW/+R -implementation being discussed here.
(**) -ECC redundancy does permit for more degradation, -more that this linking chunk that is, so that it hadly affects the -playability.
(***) -DVD "native" block size is 32KB, and 2KB -granularity is nothing but a trick, but you're excused from playing it, -i.e. reading 32KB, replacing corresponding 2KB and writing 32KB -back.
- -

- - - - - diff --git a/sources b/sources deleted file mode 100644 index 202bc88..0000000 --- a/sources +++ /dev/null @@ -1 +0,0 @@ -8acb3c885c87f6838704a0025e435871 dvd+rw-tools-7.1.tar.gz