Announcing cdrskin-1.5.6

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.5.6 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread
or OpenBSD : libc, libpthread


Changes:

* Bug fix: Overburning with cdrskin option -force ended by a libburn error
* New cdrskin option --bdr_obs_exempt

For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball which contains an own copy of libburn's
code and links it statically:

  http://scdbackup.sourceforge.net/cdrskin-1.5.6.tar.gz

There is also a detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.5.6.tar.gz.sig
by which the download may be verified:
  wget https://ftp.gnu.org/gnu/gnu-keyring.gpg
  gpg --with-fingerprint --keyring ./gnu-keyring.gpg --verify 
cdrskin-1.5.6.tar.gz.sig cdrskin-1.5.6.tar.gz
or
  gpg --keyserver keyserver.ubuntu.com --recv-keys ABC0A854
  gpg --with-fingerprint --verify cdrskin-1.5.6.tar.gz.sig cdrskin-1.5.6.tar.gz
The gpg --verify command must report
  Primary key fingerprint: 44BC 9FD0 D688 EB00 7C4D  D029 E9CB DFC0 ABC0 A854

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.5.6 git tag:
  https://dev.lovelyhq.com/libburnia/libburn/src/tag/release-1.5.6
(needs autotools >= 1.7 to apply command ./bootstrap)

and of the libburn-1.5.6 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.5.6.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:pkg-libburnia-de...@lists.alioth.debian.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

GNU xorriso 1.5.6 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.5.6
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.5.6.pl02.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr, and
MD5 checksums. It can mark boot equipment in the filesystem image so that
machine firmware finds it.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: False -status failure with -boot_image --interval:appended_partition

* Bug fix: -no_rc prevented pre-scanning of arguments for stdio output and
   others. Introduced by mistake in a62f6af5, 2011.10.18.162119.

* Bug fix: -not_leaf and -not_paths were not applied to -extract and alike

* Bug fix: -report_system_area cmd misperceived -part_like_isohybrid with
   -isohybrid-gpt-basdat

* Bug fix: -report_system_area cmd misperceived combination of isohybrid and
   appended partition in GPT

* Bug fix: -as mkisofs option -part_like_isohybrid did not cause a MBR
   partition table if the partitions are data files in the ISO
   rather than appended

* Bug fix: Split file directories (-split_size) were created with wrong
   permissions

* Bug fix: libisofs did not mark clones of imported files as imported.
   This could cause that original and clone occupy data storage
   in the newly written session. Thanks to Ivan Shmakov.

* Bug fix: Partition offset was preserved from -indev rather than from -outdev

* Bug fix: libisofs could misrepresent Rock Ridge information if many
   symbolic links or AAIP data were recorded in a directory

* Bug fix: Data files named /boot.catalog or ./boot.cat could be left out of
   the emerging ISO if the boot catalog was set to be hidden

* Bug fix: -toc reported wrong track LBA with overwritable media with
   unrecognized content (pseudo-closed)

* Bug fix: -find test -has_xattr matched "isofs." attributes
   in -xattr mode "any"

* New API call isoburn_assess_written_features()

* New API calls isoburn_igopt_set_max_ce_entries(),
  isoburn_igopt_get_max_ce_entries()

* New flag bit12 with isoburn_read_iso_head():
  Read even if start of multi-session emulation is damaged

* New -boot_image settings gpt_iso_bootable= and gpt_iso_not_ro=

* New -as mkisofs options --gpt-iso-bootable and --gpt-iso-not-ro

* New -as cdrecord option --obs_pad. Automatic no_emul_toc with -as cdrecord.

* New parameters "obs_pad" and "bdr_obs_exempt" for -dvd_obs

* New -as cdrecord option --bdr_obs_exempt

* New command -assess_indev_features

* New -find test -size

* New -compliance rules max_ce_entries=, max_ce_drop=

* Allowed lseekable device files with -cut_out.
  Proof-of-concept by Ivan Shmakov on bugs.debian.org. (Closes: #1010098)


Peculiarities of this release:

libisofs and GNU xorriso failed to compile on some non-GNU/Linux systems
because ssize_t was used in libisofs/rockridge.h but not defined.
(Reason is the generosity of GNU/Linux to define ssize_t in  and
.)

The now released state is:

- libisofs-1.5.6.pl01 has the bug fixed.

- GNU xorriso has been patched to xorriso-1.5.6.pl02.tar.gz which is now
  uploaded. (By tradition and most likely inattention i failed to fix the
  bug in .pl01, which got uploaded before i noticed my lapse.)



License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread, libvolmgt
- NetBSD   : libc, libpthread
- OpenBSD  : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development , or libedit
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

 

Re: warning: `growisofs' uses 32-bit capabilities (legacy support in use)

[Thomas Schmitt]

Hi,

Jeffrey Walton wrote:
> I'm testing a new dual layer DVD reader/writer. The write failed (a
> separate issue),

If it has an interesting cause, then i would like to learn about it
(with my libburn hat on).


> capability: warning: `growisofs' uses 32-bit capabilities (legacy support 
> in use)

I am staring at growisofs.c where syscall(SYS_capset,,) is issued.
First of all i don't understand why growisofs is setting CAP_SYS_RAWIO
at all. I never experienced the need for this in libburn.
man 7 capabilities says:
   CAP_SYS_RAWIO
  ...
  * perform various SCSI device commands;
  ...
but those which are necessary for operating optical drives work fine
without the need for CAP_SYS_RAWIO.
Probably Andy Polyakov just wants to get rid of all possibly set
capabilities except CAP_SYS_RAWIO.
I don't see any "Current:" capabilities set for a normal user in the
output of
  /sbin/capsh --print

Next i wonder why growisofs uses syscall(SYS_capset,...) instead of
capset(2) or cap_set_proc(3) or capsetp(3).


> According to http://fy.chalmers.se/~appro/linux/DVD+RW/,
> cdwrite@other.debian.org is the place for discussions about growisofs.

Andy Polyakov did not show up here since years. If the problem would
hamper burning, i would try to propose a workaround. But since i don't
even understand the motivation of the capabilities manipulation, i
refrain from a proposal.

(One could make experiments whether that code piece is needed at all.)


> It would be nice to see someone with knowledge of the issue to fix it
> once and for all nowadays.

Besides my lack of understanding with that part of growisofs, there is the
problem that a fix would have to be brought to
  http://fy.chalmers.se/~appro/linux/DVD+RW/
so that all distros can get it.


Have a nice day :)

Thomas

Re: Linux M-Disc support

[Thomas Schmitt]

Hi,

Paul von Behren wrote:
> Media current: BD-R sequential recording
> Media product: MILLEN/MR1/0 , Millenniata Inc.
> Media status : is blank
> Media blocks : 0 readable , 12219392 writable , 12219392 overall

This one should work with xorriso.


> Media current: BD-R sequential recording, Pseudo Overwrite formatted
> Media product: VERBAT/IMk/0 , Mitsubishi Kagaku Media Co.
> Media status : is unsuitable , is POW formatted
> Media blocks : 35185280 readable , 12906880 unused , 48092160 overall
> Media summary: unsuitable Pseudo Overwrite formatted BD-R

A "100 GB" medium. Must have cost nearly as much as the drive. :))

This one might still be writable by growisofs for an add-on session
with option -M.
Inquire its state by

  dvd+rw-mediainfo /dev/sr0

(The tray with the BD must already be loaded, because dvd+rw-mediainfo
won't pull it in.)

Specs for BD media offer a mode called Pseudo Overwrite where the Defect
Management is (mis-)used to replace written blocks by spare blocks if a
write operation happens again to such a written block.
growisofs uses it to update the superblock at offset 0, whereas libburn
programs rely on the convention that the operating systems mount the
superblock of the first track of the most recent session.


> I will try to burn an m-disk next with xorriso and let you know how it
> goes.

If you use the blank BD-R unformatted, then it will be written with full
nominal speed. That might become loud. Inquire the speeds by

  xorriso -outdev /dev/sr0 -list_speeds

and consider to reduce speed and noise by xorriso command -speed.


If you want Defect Management (of which i'm not overly convinced), then
let xorriso format the medium. You can do this in a separate run before
the actual write run

  xorriso -outdev /dev/sr0 -format "as_needed"

or use the -format command in the course of the first xorriso write run
which uses this medium.

"as_needed" applies the default formatting size (normally 23098 MiB).
You may get proposals for the loaded medium by:

  xorriso -outdev /dev/sr0 -list_formats

like

  Format status: unformatted, up to 23866.0 MiB
  Format idx 0 : 00h , 11826176s , 23098.0 MiB
  Format idx 1 : 32h , 11826176s , 23098.0 MiB
  Format idx 2 : 32h , 5796864s , 11322.0 MiB
  Format idx 3 : 32h , 12088320s , 23610.0 MiB

and choose other division between payload and spare blocks, by e.g.

  xorriso -outdev /dev/sr0 -format by_index_3

  xorriso -outdev /dev/sr0 -format by_size=22586m

(More than 23866m will not be achievable, of course.)


Have a nice day :)

Thomas

Re: Linux M-Disc support

[Thomas Schmitt]

Hi,

Paul von Behren wrote:
> Can xorriso burn/engrave an M-Disc? Can any other Linux SW?

Yes to both, although rarely tested.
In my mailbox i find libburn user reports only for BD-R M-Discs.

M-Disc is entirely a matter of drive and medium. The burn programs get
the media info from the drive which presents M-Disc as DVD+R or BD-R.
(Verbatim seems to sell M-Disc DVD as "DVD R" omitting the significant
difference between DVD-R and DVD+R. But i remember that DVD+R was
mentioned when the M-Disc technology was announced.)

So if you really want to pay the price difference between M-Disc and
other write-once media, then give it a try with your favorite burn
program for DVD or BD.
I would of course be glad if you choose xorriso or cdrskin.

Please report the outcome.
As said: Reports are rare.

--

If the burn run looks successful, consider to run

  xorriso -for_backup -indev /dev/sr0 -check_media --

to get an impression of readability.

If you use xorriso to create an ISO 9660 filesystem, then consider to
use -for_backup to equip the data files and the overall filesystem with
MD5 checksums. (With xorriso's mkisofs emulation the option begins by
two dashes: --for_backup.)

A xorriso run with -for_backup ... -check_media will then verify the
overall checksums.
But even without recorded MD5s it will check the readability of all data
blocks of the written area.


If you recorded MD5 and want to check the single file checksums:

  xorriso -for_backup -indev /dev/sr0 -check_md5_r sorry / --

This will report on stdout each file which fails to match its recorded
MD5. Informational messages and pacifiers appear on stderr.
The exit status of xorriso will indicate whether all was fine (0) or
whether files failed the test (not 0, actually 32).
This check works only if indeed MD5s were recorded by xorriso.

Consider to repeat this checking regularly to get an impression how your
recorded files are doing.


Have a nice day :)

Thomas

Re: Add genisoimage parameter -keep-top-dirs

[Thomas Schmitt]

Hi,

Kai Engert wrote:
> If growisofs is going to survive for another few years, then maybe it's
> worth keeping the toolchain alive? (which requires genisoimage)

xorriso can substitue for mkisofs and genisoimage by help of its link
"xorrisofs" and the growisofs variable "MKISOFS". man xorrisofs has
an example:

$ export MKISOFS="xorrisofs"
$ growisofs -Z /dev/dvd /some/files
$ growisofs -M /dev/dvd /more/files
  If  no  "xorrisofs"  is available on your system, then you will have to
  create a link pointing to the xorriso binary and tell growisofs to  use
  it. E.g. by:
$ ln -s $(which xorriso) "$HOME/xorrisofs"
$ export MKISOFS="$HOME/xorrisofs"


> Is there a primary repository somewhere (e.g. github) that is equivalent to
> the most recent cdrkit release that debian and fedora packages are based on?

The original repo is gone, i fear.
This here looks like going back to the fork from cdrtools in 2006:
  https://code.launchpad.net/ubuntu/+source/cdrkit

It knows my Launchpad Id and offers
  git clone git+ssh://scdbac...@git.launchpad.net/ubuntu/+source/cdrkit
I guess you get at least offered
  git clone https://git.launchpad.net/ubuntu/+source/cdrkit


> Is there an official download location for the most recent tar archive, or
> would it be fine to simple use the archive found in the debian package?

The most recent Debian package
  https://packages.debian.org/unstable/genisoimage
is obviously based on
  http://deb.debian.org/debian/pool/main/c/cdrkit/cdrkit_1.1.11.orig.tar.gz
  
http://deb.debian.org/debian/pool/main/c/cdrkit/cdrkit_1.1.11-3.2.debian.tar.xz
You may inspect the source online at
  https://sources.debian.org/src/cdrkit/9:1.1.11-3.2/


> Maybe Sam's other changes should be ignored / kept separate.

At least other changes should be kept out of the game until you unpacked
the original source, applied at least the two bitrot patches from
  https://sources.debian.org/src/cdrkit/9:1.1.11-3.2/debian/patches/
(namely "fix_libcap_detection.patch" and "gcc10.patch".),
and managed to build the binaries.


> Regarding the 2038 issue and time64_t, you referred to a iso_date function
> and to a filename that I cannot find in the cdrkit archive.

That bug sits in the Linux kernel. Line 19 and 22 in
  https://github.com/torvalds/linux/blob/master/fs/isofs/util.c
Line 109 in
  https://github.com/torvalds/linux/blob/master/fs/isofs/isofs.h


> Regardless, is my understanding correct that the 2038 bug will be limited to
> 32bit platforms, because on 64bit platforms time_t is already sufficiently
> big to avoid the 2038 bug?

The current type is int, not time_t. I don't expect that int will
become 64 bit on the then mainstream architectures before kernels get
compiled which are expected to be still on duty when 2038 arrives.

I have a patch with demonstration of the problem by

  xorriso -outdev /tmp/test_date.iso \
  -blank as_needed \
  -map /bin/true /victim \
  -alter_date m 'Oct 01 22:06:12 2040' /victim --

When mounted the kernel returns the victim's timestamp as
  Aug 26  1904


But i gave up on submitting Linux patches after even a kernel Oops on
powerpc64 was ignored.

Maybe i learn to know somebody until 2038 who has the standing to get
at least a review for a patch submission.
(Another isofs bug is about Rock Ridge names of byte length 254 or 255,
which get shown massively truncateid by Linux - up to name collisions.
More bugs are around in cdrom and sr.)


Have a nice day :)

Thomas

Re: Add genisoimage parameter -keep-top-dirs

[Thomas Schmitt]

Hi,

Kai Engert wrote:
> I'm attaching a patch to add a new parameter -keep-top-dirs to
> genisoimage.

I guess that you will have to take over upstream maintainership of cdrkit
if you want to get any changes published.

cdrkit was in danger of getting erased from Debian.
John Paul Adrian Glaubitz adopted it as Debian maintainer:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974914
Afaik, his main motivation is to keep genisoimage alive.
So he would be your natural ally.

I would be your competitor, but not your enemy. :)
(See below for a proposal how to perform your use case with xorriso.)

If you plan to use genisoimage for several more years, then consider
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990468
  "genisoimage: Bad time stamps for post-2027 files"

(The next timestamp bug would be in Linux, where the time value is
squeezed through the 32-bit return value of fs/isofs/util.c function
iso_date(). Rollover will happen in 2038. Solution would be to change
the type of iso_date() and its local variable crtime from int to time64_t.
In 2155 the year field of the ISO 9660 format will overflow.)

-

xorriso's command -add can do what you strive for:

  xorriso -for_backup -outdev output.iso -add 2015-* --

In order to burn the ISO directly onto optical medium:

  xorriso -for_backup -outdev /dev/sr0 -add 2015-* --

If the locations of the input file objects are not as simple, then you
could use xorriso commands -cdx and -disk_pattern:

  xorriso -for_backup -outdev output.iso -disk_pattern on \
  -cdx "$HOME"/archive -add '2015-*' -- \
  -cdx /home/guest -add '*-backup' '*-archive' --

Note that in this example the patterns get protected by quotation marks
from being expanded by the shell parser. The expansion will be done by
xorriso in the current -cdx directory, because -disk_pattern is "on".
(Still the -add commands need their terminating "--" arguments.)

I propose to use xorriso command -for_backup. Mainly for getting MD5
checksums which can later be verified by commands like in:

  xorriso -for_backup -indev /dev/sr0 -check_media --

  xorriso -for_backup -indev /dev/sr0 -check_md5_r sorry / --

(Would of course also work with: -indev output.iso )


Have a nice day :)

Thomas

Code for SCSI transaction log in dvd+rw-tools

[Thomas Schmitt]

Hi,

 

attached is a patch to let dvd+rw-tools report its SCSI transactions
on stderr.

 

The patch is based on growisofs-7.1.tar.gz of march 2008.
At least one of the changes is already addressed by Debian's dvd+rw-tools:

 

  +/* To compensate bit rot: "INT_MAX was not declared in this scope"
  +*/
  +#include 
  +

 

Another noteworthy aspect is that the log cannot be enabled or disabled
at run time, but only at compile time. A new private variable of
class Scsi_Command and a setter method for it would be an improvement.

 

Have a nice day :)

 

Thomas

 --- dvd+rw-tools-7.1.orig/transport.hxx	2008-03-01 11:34:43.0 +0100
+++ dvd+rw-tools-7.1.scsi_log/transport.hxx	2018-03-23 09:03:00.466581766 +0100
@@ -6,6 +6,12 @@
 // For further details see http://fy.chalmers.se/~appro/linux/DVD+RW/
 //

+
+/* If this is defined, then the SCSI transactions are logged to stderr.
+*/
+#define Libburnish_scsi_log_to_stderR 1
+
+
 #if defined(__unix) || defined(__unix__)
 #include 
 #include 
@@ -17,6 +23,10 @@
 #include 
 #include 

+/* To compensate bit rot: "INT_MAX was not declared in this scope"
+*/
+#include 
+
 inline long getmsecs()
 { struct timeval tv;
 gettimeofday (,NULL);
@@ -281,8 +291,17 @@ public:
 	{   sg_io.dxferp		= buf;
 	sg_io.dxfer_len		= sz;
 	sg_io.dxfer_direction	= use_sg_io[dir];
+
+#ifdef Libburnish_scsi_log_to_stderR
+show_cmd_text(_io, stderr, 0);
+#endif /* Libburnish_scsi_log_to_stderR */
+
 	if (ioctl (fd,SG_IO,_io)) return -1;

+#ifdef Libburnish_scsi_log_to_stderR
+show_cmd_reply(_io, stderr, 0);
+#endif /* Libburnish_scsi_log_to_stderR */
+
 #if !KERNEL_BROKEN
 	if ((sg_io.info_INFO_OK_MASK) != SG_INFO_OK)
 #else
@@ -312,6 +331,136 @@ public:
 	}
 	return ret;
 }
+
+#ifdef Libburnish_scsi_log_to_stderR
+#ifdef SG_IO
+/* This is my own code from libburn adapted to Linux SG_IO rather than
+   the generic command structure of libburn.
+   Permission is granted to use it in any way.
+   Thomas Schmitt, scdbac...@gmx.net, 2009
+*/
+char *scsi_command_name(unsigned int c, int flag)
+{
+	switch (c) {
+case 0x00:
+		return (char *) "TEST UNIT READY";
+case 0x03:
+		return (char *) "REQUEST SENSE";
+case 0x04:
+		return (char *) "FORMAT UNIT";
+case 0x1b:
+		return (char *) "START/STOP UNIT";
+	case 0x12:
+		return (char *) "INQUIRY";
+	case 0x1e:
+		return (char *) "PREVENT/ALLOW MEDIA REMOVAL";
+case 0x23:
+		return (char *) "READ FORMAT CAPACITIES";
+case 0x25:
+		return (char *) "READ CAPACITY";
+case 0x28:
+		return (char *) "READ(10)";
+case 0x2a:
+		return (char *) "WRITE(10)";
+case 0x35:
+		return (char *) "SYNCHRONIZE CACHE";
+case 0x43:
+		return (char *) "READ TOC/PMA/ATIP";
+case 0x46:
+		return (char *) "GET CONFIGURATION";
+case 0x4a:
+		return (char *) "GET EVENT STATUS NOTIFICATION";
+case 0x51:
+		return (char *) "READ DISC INFORMATION";
+case 0x52:
+		return (char *) "READ TRACK INFORMATION";
+case 0x53:
+		return (char *) "RESERVE TRACK";
+case 0x54:
+		return (char *) "SEND OPC INFORMATION";
+case 0x55:
+		return (char *) "MODE SELECT";
+	case 0x5a:
+		return (char *) "MODE SENSE";
+case 0x5b:
+		return (char *) "CLOSE TRACK/SESSION";
+case 0x5c:
+		return (char *) "READ BUFFER CAPACITY";
+case 0x5d:
+		return (char *) "SEND CUE SHEET";
+case 0xa1:
+		return (char *) "BLANK";
+case 0xaa:
+		return (char *) "WRITE(12)";
+case 0xac:
+		return (char *) "GET PERFORMANCE";
+case 0xad:
+		return (char *) "READ DISC STRUCTURE";
+case 0xb6:
+		return (char *) "SET STREAMING";
+case 0xbb:
+		return (char *) "SET CD SPEED";
+case 0xbe:
+		return (char *) "READ CD";
+	}
+	return (char *) "(NOT IN COMMAND LIST)";
+}
+int show_cmd_text(sg_io_hdr_t *s, FILE *fp, int flag)
+{
+	int i;
+
+	fprintf(fp, "\n%s\n",
+		 scsi_command_name((unsigned int) s->cmdp[0], 0));
+	for(i = 0; i < 16 && i < s->cmd_len; i++)
+		fprintf(fp, "%2.2x ", s->cmdp[i]);
+	if (i > 0)
+		fprintf(fp, "\n");
+	if (flag & 1)
+		return 1;
+	if (s->cmdp[0] == 0x2A) { /* WRITE 10 */
+		;
+	} else if (s->cmdp[0] == 0xAA) { /* WRITE 12 */
+		;
+	} else if (s->dxfer_direction == SG_DXFER_TO_DEV) {
+		fprintf(fp, "To drive: %db\n", s->dxfer_len);
+		for (i = 0; i < s->dxfer_len; i++)
+			fprintf(fp, "%2.2x%c", ((unsigned char *) s->dxferp)[i],
+((i % 20) == 19 ? '\n' : ' '));
+		if (i 

Re: Spare Tables error on format

[Thomas Schmitt]

Hi,

i wrote:
> > Well, i seem to have more drives attached than you. :))

Listas Canal wrote:
> I have 2 BD-RE and 1 DVD-RW, yes you have 1 more :))

But sr4 is drive number 5. And i have a sr5.

0  -dev '/dev/sr0' rwrw-- :  'HL-DT-ST' 'BDDVDRW GGC-H20L'
1  -dev '/dev/sr1' rwrw-- :  'HL-DT-ST' 'DVDRAM GH24NSC0'
2  -dev '/dev/sr2' rwrw-- :  'HL-DT-ST' 'BD-RE GGW-H20L'
3  -dev '/dev/sr3' rwrw-- :  'Optiarc ' 'BD RW BD-5300S'
4  -dev '/dev/sr4' rwrw-- :  'ASUS' 'BW-16D1HT'
5  -dev '/dev/sr5' rwrw-- :  'HL-DT-ST' 'BD-RE BH16NS40'


> >  Media summary: 610 sessions, 9060897 data blocks, 17.3g data, 5894m free

> Did you recycle the one on the shelf when another 2 or more came? 

No. I still have them since i began using that scheme in 2010.
Above backup has compression by zisofs and thus produces quite small
sessions.
In the beginning i used BD-R for it, but even the nicest burners refuse
to burn more than about 300 session to them. With BD-RE there is no need
for the drive to maintain an own table-of-content. It sees only one big
track. So the chain of ISO 9660 sessions can get as long as the medium
has capacity.


> I hope BD-RE also has the
> same durability or more for confidential data that grows from year to year.

I recently performed BD-R tests by copying BD-REs of 2010, made by the
GGW-H20L. (That old burner does not accept any contemporary BD-R for
burning but still does bulk BD-RE backups for me with its sensational 2.3x
speed.)
Half of the copied BD-REs later turned out to be unreliable for writing.
So my hope for a big recycling outcome was disappointed.
But before that they all were readable and passed their MD5 content checks.

On the other hand i have BD-RE from 2008 which get overwritten once every
half year.


> > (You could insert a command spy in method Scsi_Command.transport()
> >  of the file transport.hxx. The diff between original and spying version
> >  of transport.hxx has 179 lines. Ask me if you want to have it.)

> Yes please, if you can share it as an attachment.

I'm not sure whether this list takes attachments. So i will try by a
separate mail.


Have a nice day :)

Thomas

Re: Spare Tables error on format

[Thomas Schmitt]

Hi,

Listas Canal wrote:
> user@mtrog64:~$ dvd+rw-format -f /dev/sr1 -ssa=262144000
> ...
> * formatting .:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER
> LIST]: Input/output error

My current theory is that this is because of formatting sub type 3 Quick
Certification.


> user@mtrog64:~/Documentos/db/dvdrwtools/dvd-rw-tools$ ./dvd+rw-format
> /dev/sr1 -force=full -ssa=min
> ...
> * formatting .:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER
> LIST]: Input/output error
>
> Also commenting out the block for Quick Certification, does not work.

So my theory seems wrong.
Now it would be interesting to see what dvd+rw-format sent as cmd[0] to
cmd[7] and as formats[i] to formats[i + 11].


> Wondering how you printf f[0]..f[7] I've tried as char and int, and I've got
> different values per run.

"char" is a tricky data type in C. It's signedness differs from CPU type
to CPU type. SCSI bytes are meant unsigned and often are mentioned in
the specs as hexadecimal XYh. So one should cast them to unsigned and use
printf formatter %x or %X.

I have in one of my modified versions of dvd+rw-format.cpp :

{ int j;
fprintf(stderr, "BD-RE FORMAT command:");
for (j = 0; j < 8; j++)
fprintf(stderr, " %2.2x", (unsigned int) cmd[j]);
fprintf(stderr, "\nParameter list:");
for (j = 0; j < 12; j++)
fprintf(stderr, " %2.2x", (unsigned int) formats[i + j]);
fprintf(stderr, "\n");
}

It is inserted between

if (full && (formats[i+4+4]>>2)!=0x31)
formats[i+4+4] |= 2;// "Full Certificaton"
else if ((formats[i+4+4]>>2)==0x30)
formats[i+4+4] |= 3;// "Quick Certification"

and

if ((err=cmd.transport(WRITE,formats+i,12)))
sperror ("FORMAT UNIT",err), exit(1);

(You could insert a command spy in method Scsi_Command.transport()
of the file transport.hxx. The diff between original and spying version
of transport.hxx has 179 lines. Ask me if you want to have it.)

The meaning of the bytes is specified in SCSI volumes SPC and MMC.
I wrote a guideline text
  https://dev.lovelyhq.com/libburnia/libburn/raw/branch/master/doc/cookbook.txt
which quotes heavily from the meanwhile unavailable drafts of those
specs. Regrettably T10 demands money for the PDFs of SPC and MMC and
hid the drafts from the public. But
  https://en.wikipedia.org/wiki/MultiMedia_Commands
has a link to a PDF which sits in a directory with old draft copies.
(I do not mention its URL here, because else that last source of free
SCSI wisdom could vanish, too.)

--
Smalltalk and anecdotes:

> libburn : FAILURE : File object '/dev/sr4' not found

Well, i seem to have more drives attached than you. :))


> user@mtrog64:~$ xorriso -outdev /dev/sr1 -format fast_by_index_4
> ...
> user@mtrog64:~$ xorriso -outdev /dev/sr1 -list_formats          
> ...
> Format status: formatted, with 23866.0 MiB
> BD Spare Area: 0 blocks consumed, 0 blocks available

I rarely use BD-RE without spare area. But given the poor performance
of Defect Management it is plausible to do so, at least for single
session use cases.
With multi-session i would propose minimal spare area because the
emulation of multi-session needs to overwrite the first 64 blocks for
each session. The other blocks get written only once until the medium
is reused from scratch (after pseudo-blanking).

I have a BD-RE which takes a small incremental update session every day
since imeanwhile 20 months:
  Media summary: 610 sessions, 9060897 data blocks, 17.3g data, 5894m free
Next spring or summer i will have to put it on the shelf and start with
a blank BD-RE again.


> I was enchanted by optical media, because the price/durability is more
> affordable than SSD or USBs.

I began to love them after a DAT tape drive at work turned out to have
made bad backups for two years and the last usable backup was on an old
QIC tape for which we had to buy a used drive to be able to read it.
I gained reputation by presenting new backups as ISO 9660 on CD which the
boss could put into his own desktop computer to check by normal means
whether his favorite files are there and readable. Especially he loved
that he could read the files but not alter them, and that he could read
the backup media at home.
Oh yeah. The late 1990s ...


Have a nice day :)

Thomas

Re: Spare Tables error on format

[Thomas Schmitt]

Hi,

if you can afford to wait the up to 5000 seconds for a full format,
then try

  dvd+rw-format -force=full /dev/sr0 -ssa=min

-
Long story:

I found an old modified dvd+rw-tools directory which i used to spy on
growisofs when i noticed behavior differences between it and libburn.
(Substantial parts of libburn's DVD and BD knowledge was learned from
dvd+rw-tools. But the need to see its actual SCSI transactions came up
later when supporting growisofs users.)

The failing SCSI command transaction is

  FORMAT UNIT
  04 11 00 00 00 00
  To drive: 12b
  00 82 00 08 00 b8 74 00 c3 00 10 00
  +++ key=5  asc=26h  ascq=00h   ( 4 ms)

FOV bit and Immed bit are set in the Format List Header.
8 bytes are announced for the Format Descriptor, which requests 0xb87400
= 12088320 blocks, which is indeed the largest possible payload and thus
requests the smallest possible size of the Spare Area.
Format Type is 0x30 (BD-R or BD-RE with spares).
Format-Subtype is 3 (Quick Certification).
Type Dependend Parameter is 0x00 0x010 0x00.

Spying on libburn by

  xorriso -scsi_log on -outdev /dev/sr4 -format fast_by_index_3 \
2>&1 | tee -i /tmp/xorriso.log

yields this successful transaction

  FORMAT UNIT
  04 11 00 00 00 00
  To drive: 12b
  00 82 00 08 00 b8 74 00 c0 00 10 00

The only difference to dvd+rw-format is the Format-Subtype:
0 (Quick Reformat) instead of 3 (Quick Certification).


Now i begin to find traces in libburn. A comment from 2008 says
   LG GGW-H20L YL03 refuses on 0x30 with
   "Quick certification". dvd+rw-format
   does 0x00 by default and succeeds quickly.
Newer is a test for the Quick Certification flag in feature 23h,
which would prevent Sub-type 3 if not set.

Looking at
  https://sources.debian.org/src/dvd+rw-tools/7.1-14/dvd%252Brw-format.cpp/#L791
which has

if (full && (formats[i+4+4]>>2)!=0x31)
formats[i+4+4] |= 2;// "Full Certificaton"
else if ((formats[i+4+4]>>2)==0x30)
formats[i+4+4] |= 3;// "Quick Certification"

gives the idea that a run of

  dvd+rw-format -force=full /dev/sr0 -ssa=min

might succeed.

(My test BD-RE currently gets a -format by_index_3 run of xorriso and
will be ready for more experiments in an hour and a half ...)



If -force=full helps, then a patch candidate would be to replace

formats[i+4+4] |= 3;// "Quick Certification"

by a no-op (the 0 is already written to formats[i+4+4]):

; // "Quick Reformat" because "Quick Certification" often fails

I am not sure whether this will work with all drives.
Maybe better would be to inquire bit 2 of byte 4 of feature 23h from the
GET CONFIGURATION command which already inquires the mmc_profile, i.e.
the current media type and personality.
If that bit is not set, then libburn uses Format Sub-Type 0 instead of 3
or 2 ("Full Certification").


Further i will have to find out why both softwares send a Type Dependend
Parameter that is not all 0. Might be debris from the Format Descriptors
which gets sent back to the drives. Only good that they gracefully ignore
that 0x10 byte.


Have a nice day :)

Thomas

Re: Spare Tables error on format

[Thomas Schmitt]

Hi,

Listas Canal wrote:
> Hello dear list:I don't know if here can I ask about dvd+rw-format, the
> autor of dvd+rw-tools points this list.

Well, he seems to be out of the burn business since a decade.
Being developer of libburn and xorriso, i seem to be the last remaining
active carer of optical drives in the free software world. A lonely job.


> dvd+rw-tools-7.1$ ./dvd+rw-format -f /dev/sr0 -ssa=32m

It looks like your -ssa= value is too small for BD-RE.

MMC-5, 6.5.4.2.15.3 "Spares Allocation on Single Layer BD-RE" says that
there must be at least 4096 * 32 = 131072 blocks = 256 MiB of spare
area (or none at all).
That paragraph predicts the error reply
   ILLEGAL REQUEST/INVALID FIELD IN PARAMETER LIST
which you see with your run.

It seems wrong that dvd+rw-format's understands your "32m" as 32.0e6,
and then computes the desired number of blocks by dividing by 2.0e3.
Actually block size is 2*1024.
  https://sources.debian.org/src/dvd+rw-tools/7.1-14/dvd%252Brw-format.cpp/#L285
So "32m" leads to 16,000 blocks instead of 16384.

I expect that

  -ssa=262144000

yields the minimal permissible number of 131072 blocks.


> only -ssa=none or -ssa=default is working. max and min also does not work.

I did not use dvd+rw-format in years.

  $ dvd+rw-format -f /dev/sr4 -ssa=min
  * BD/DVD±RW/-RAM format utility by , version 7.1.
  * 24.5GB BD media detected.
  * formatting .:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER 
LIST]: Input/output error
  $

Wow. That was quick.

With xorriso i would do it like:

  $ xorriso -outdev /dev/sr4 -list_formats
  ...
  Format status: formatted, with 23354.0 MiB
  BD Spare Area: 0 blocks consumed, 262144 blocks available
  Format idx 0 : 00h , 11826176s , 23098.0 MiB
  Format idx 1 : 30h , 11826176s , 23098.0 MiB
  Format idx 2 : 30h , 11564032s , 22586.0 MiB
  Format idx 3 : 30h , 12088320s , 23610.0 MiB
  Format idx 4 : 31h , 12219392s , 23866.0 MiB

  $ xorriso -outdev /dev/sr4 -format fast_by_index_3
  ...
  Beginning to format medium.
  xorriso : UPDATE : Formatting  ( 1.0% done in 1 seconds )
  xorriso : UPDATE : Formatting  ( 1.0% done in 2 seconds )
  xorriso : UPDATE : Formatting  ( 1.0% done in 3 seconds )
  xorriso : UPDATE : Formatting  ( 1.0% done in 4 seconds )
  xorriso : UPDATE : Formatting  ( 7.0% done in 5 seconds )
  xorriso : UPDATE : Formatting  ( 7.0% done in 6 seconds )
  xorriso : UPDATE : Formatting  ( 12.9% done in 7 seconds )
  Formatting done
  ...

  $ xorriso -outdev /dev/sr4 -list_formats
  ...
  Format status: formatted, with 23610.0 MiB
  BD Spare Area: 0 blocks consumed, 131072 blocks available
  ...

I fail to understand what goes wrong in dvd+rw-format with -ssa=min.
The code is quite condensed but after some riddling it seems correct.
It looks for the format descriptor with the highest capacity and uses
its data to request that capacity via the FORMAT UNIT command.

Pity that dvd+rw-format does not offer a debugging mode which would
show its SCSI transactions, like with xorriso -scsi_log on.

Whatever, even if we find the bug, there is few hope that Debian will
add a patch to its dvd+rw-tools package. I have a DVD-R[W] patch pending
there since 6 years.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794868

So i can only invite you to find the bugs in xorriso's formatting code.
See above example and also the description of command -format in
man xorriso.


Have a nice day :)

Thomas

In memoriam Joerg Schilling

[Thomas Schmitt]

With deep regret i have to report that i just learned of Joerg Schilling's
death.

To me he was first the only provider of burn software and later a
respected competitor and discussion adversary. We were not often in
agreement, but we cared - if not to say we burned - for the same issue.

The thought that i will never again see his posts in the internet
saddens me. May he rest in peace.

Thomas Schmitt, libburnia project

Announcing cdrskin-1.5.4

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.5.4 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread
or OpenBSD : libc, libpthread


Changes:

* Bug fix: Early SCSI commands from sg-linux.c were not logged


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball which contains an own copy of libburn's
code and links it statically:

  http://scdbackup.sourceforge.net/cdrskin-1.5.4.tar.gz

There is also a detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.5.4.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.5.4.tar.gz.sig cdrskin-1.5.4.tar.gz
The gpg --verify command must report
  Primary key fingerprint: 44BC 9FD0 D688 EB00 7C4D  D029 E9CB DFC0 ABC0 A854


scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.5.4 git tag:
  https://dev.lovelyhq.com/libburnia/libburn/src/tag/release-1.5.4
(needs autotools >= 1.7 to apply command ./bootstrap)

and of the libburn-1.5.4 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.5.4.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:pkg-libburnia-de...@lists.alioth.debian.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

GNU xorriso 1.5.4 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.5.4
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.5.4.pl02.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr, and
MD5 checksums. It can mark boot equipment in the filesystem image so that
machine firmware finds it.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: Large amounts of AAIP data or many long file names could cause
   with zisofs an unreadable filesystem after the warning
   "Calculated and written ECMA-119 tree end differ"

* Bug fix: -report_system_area as_mkisofs misrepresented GPT with appended
   partition and forced boot flag as -part_like_isohybrid

* Bug fix: Boot catalog could get a wrong name if cat_path= is explicitely
   given but not containing a slash character

* Bug fix: Big-Endian MIPS Volume Header boot file size was rounded up to
   full 2048. Thanks René Rebe.

* Bug fix: El Torito production failed if no catalog path is given and the
   first boot image path contains no slash

* Bug fix: zisofs production was wrong on big-endian machines

* Bug fix: Appended APM partitions without HFS+ production had start and size 1

* Bug fix: On GNU/Linux early SCSI commands were not logged

* New helper script xorriso-dd-target

* New command -truncate_overwritable

* Switched to usage of libjte-2.0.0

* New -jigdo parameters "checksum_algorithm", "demand_checksum",
  "-checksum-list"

* New -as mkisofs options "-jigdo-checksum-algorithm", "-checksum-list",
  "-jigdo-force-checksum"

* New -read_speed prefixes "soft_force:" and "soft_corr:"

* New -check_media option data_to="-" for standard output

* New -zisofs parameters version_2=, block_size_v2=, max_bpt=, max_bpt_f=,
  bpt_target=, bpt_free_ratio=, by_magic=v2, susp_z2=

* New -as mkisofs options --zisofs-version-2, --zisofs2-susp-z2,
  --zisofs2-susp-zf

* Enabled recognition of zisofs by magic without zlib support

* New -osirrox option sparse= controls extraction into sparse files

* New libisoburn extension options isoburn_ropt_map_joliet_stripped and
  isoburn_ropt_map_joliet_unmapped

* New command -joliet_map

* New command -extract_boot_images

* New API call isoburn_ropt_get_tree_loaded()


Peculiarities of this release:

A 5 year old bug of libisofs about zisofs was reported when the release
tags in git already existed and GNU xorriso-1.5.4.tar.gz was already
uploaded. This halted the final steps of the release for a week.

The now released state is:

- libisofs-1.5.4 has the bug fixed. Because no upload had happened yet,
  the tarball still goes by the name libisofs-1.5.4.tar.gz .
  The old libisofs release tag was changed to "release-1.5.4.rc1".
  The current tag "release-1.5.4" marks the code state of the now released
  libisofs-1.5.4.tar.gz .

- GNU xorriso has been patched to xorriso-1.5.4.pl02.tar.gz which is now
  uploaded. (By a moment of inattention i failed to fix the bug in .pl01,
  which got uploaded before i noticed. I feel duely embarrassed.)



License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread, libvolmgt
- NetBSD   : libc, libpthread
- OpenBSD  : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development , or libedit
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net .

Download:

The xorriso release tarball will soon show up at your local GNU FTP mirror as
  

Re: Can Bluray Players see ISO9660 Filesystems?

[Thomas Schmitt]

Hi,

Roger wrote:
> Glad to see a heart beat on this mailing list!  After sending, thought this
> mailing list was completely  inactive!

It nearly is inactive. Once it was a common discussion forum for
free burn programs. I fear that we have no Blu-ray video experts here.


> I noticed the "-udf" option for mkisofs [...] creating
> a bridged or hybrid type filesystem. [...]
> So this should create a
> readable BD-R media for TV bluray players, but not necessarily playable due
> to a missing directory structure/file?

Afaik, mkisofs can prepare an UDF hybrid for DVD video players.
See its option -dvd-video and the examples in the web.
There are tools like http://dvdauthor.sourceforge.net/ which use mkisofs
to produce the UDF filesystem around their video specific files.
But for Blu-ray there seems to be no similar tool.


i wrote:
> >Try (by a BD-RE medium to avoid waste)

> Yup, after two days, finally found my boxed-up DVD+RW & BD-RE media.
> Making this a little more difficult, the Linux pktcdvd driver is slated as
> deprecated/removal, albeit oddly since 2016 and still is within the kernel.

You don't need pktcdvd if you burn the medium by a burn program.

This driver is needed only if you want to write by normal POSIX I/O
functions to formatted CD-RW or DVD-RW. Its job is to bundle the write
operations to full 32 KiB chunks, which the media in question expect
as transaction size.

DVD-RAM, DVD+RW, and BD-RE have a transaction size of 2 KiB. They can
be written by POSIX means without the help of pktcdvd. I.e. you can format
a filesystem on them and mount it for reading and writing.
(Only problem is that it will be darn slow, make noises, and wear off
 your BD drive quicker than burn programs would do.)


> Hopefully I don't have to waste money on a TV bluray player for checking on
> this filesystem readability issue.

I would expect mixed results, depending on the age and maker of the player.
If you need to have the BD play on arbitrary players, then i expect that
you have to use a Blu-ray authoring tool on MS-Windows or MacOS.


Have a nice day :)

Thomas

Re: Can Bluray Players see ISO9660 Filesystems?

[Thomas Schmitt]

Hi,

Roger wrote:
> Can bluray players view ISO9660 filesystems?

It depends on the operating system that shall interpret the filesystem.
If the Blu-ray drive is attached to a PC-like computer with general
purpose operating system, then: yes.
If the drive is in a video player box with its own (obscure) operating
system, then ISO 9660 might not be usable.


> If so, is it preferable to still use "growisofs -udf -iso-level 3 ..."?

Option -udf will give it a UDF superblock and directory tree. Most
system will prefer this over the ISO 9660 superblock and tree.


> Suggestions feedback for creating/backing-up photos/video to BDR with TV
> Bluray player hardware support?

Wikipedia says you need UDF 2.50 or higher and you have to provide a
particular directory structure:
  https://en.wikipedia.org/wiki/Blu-ray#Data_format_standards
I am not aware of a program which would produce this on Linux or BSD.
Some people use Wine and old versions of MS-Windows Blu-ray authoring
programs.

Try (by a BD-RE medium to avoid waste) whether your target player can
access files in the UDF version of growisofs/mkisofs or in ISO 9660.


Have a nice day :)

Thomas

Bug fix release cdrskin-1.5.2.pl01

[Thomas Schmitt]

Hi,

it turned out that cdrskin-1.5.2 did not properly burn multiple tracks.
The bug was introduced by cdrskin-1.5.0. Its fix is in
  
https://dev.lovelyhq.com/libburnia/libburn/commit/91f7d4d34a28b00a26292fa9498f0d4f78a5dfb7

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread


Changes:

* Bug fix: cdrskin multi-track burning was slow and stalled after track 1.
   Regression introduced in version 1.5.0 by commit 84fad99, 2018.02.05.
   O_DIRECT is now disabled for track sources.


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.5.2.pl01.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.5.2.pl01.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.5.2.pl01.tar.gz.sig cdrskin-1.5.2.pl01.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.5.2.pl01 SVN tag:
  https://dev.lovelyhq.com/libburnia/libburn/tree/release-1.5.2.pl01
(needs autotools >= 1.7 to apply command ./bootstrap)

and of the libburn-1.5.2.pl01 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.5.2.pl01.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:pkg-libburnia-de...@lists.alioth.debian.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

Announcing cdrskin-1.5.2

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.5.2 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread
or OpenBSD : libc, libpthread


Changes:

* Bug fix: Stream recording was applied regardless whether the drive offers it.
   This caused failures with some MATSHITA laptop drives if
   stream_recording= was enabled.

* Bug fix: TDK Corporation was not recognized as manufacturer of DVD-R "TTH02"

* Made libburn ready for building out-of-source.  Thanks Ross Burton.

* New cdrskin option --list_features


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.5.2.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.5.2.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.5.2.tar.gz.sig cdrskin-1.5.2.tar.gz
The gpg --verify command must report
  Primary key fingerprint: 44BC 9FD0 D688 EB00 7C4D  D029 E9CB DFC0 ABC0 A854


scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.5.2 git tag:
  https://dev.lovelyhq.com/libburnia/libburn/tree/release-1.5.2
(needs autotools >= 1.7 to apply command ./bootstrap)

and of the libburn-1.5.2 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.5.2.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:pkg-libburnia-de...@lists.alioth.debian.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

GNU xorriso 1.5.2 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.5.2
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.5.2.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: Stream recording was applied regardless whether the drive offers it.
   This caused failures with some MATSHITA laptop drives if
   -stream_recording was enabled.

* Bug fix: TDK Corporation was not recognized as manufacturer of DVD-R "TTH02"

* Bug fix: Appended GPT partitions were not covered by the protective MBR
   partition

* Bug fix: Multi-session emulation spoiled GPT production.
   "GPT partitions ... overlap". Regression towards 1.4.8

* Bug fix: Appending partitions 5 to 8 caused damaged ISO filesystems if not
   for SUN disk label

* Bug fix: SIGSEGV happened if --grub2-boot-info was given without -b

* Bug fix: -disk_pattern on -add ./ -- mistook "./" for the root directory.
   Thanks JBThiel.

* Bug fix: -disk_pattern "on" -add "" -- yielded SIGSEGV

* Bug fix: -osirrox "concat_split_on" worked only together with -split_size
   larger than 0. Thanks William Willems.

* Enabled GPT type GUIDs with -append_partition,
  -boot_image any iso_mbr_part_type=, and -as mkisofs -iso_mbr_part_type

* Made libisoburn and GNU xorriso ready for building out-of-source.
  Thanks Ross Burton.

License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread, libvolmgt
- NetBSD   : libc, libpthread
- OpenBSD  : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development , or libedit
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net .

Download:

The xorriso release tarball will soon show up at your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.5.2.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.5.2.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

Announcing cdrskin-1.5.0

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.5.0 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread
or OpenBSD : libc, libpthread


Changes:

* Bug fix: cdrskin threw errno 22 on data file input if libburn is
   configured with --enable-track-src-odirect

* Bug fix: SIGSEGV could happen if a track ended by reaching its fixed size
   while the track source still was willing to deliver bytes.
   Thanks to user swordragon.

* Bug fix: Device file comparison parameters were recorded wrong with Linux sg


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.5.0.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.5.0.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.5.0.tar.gz.sig cdrskin-1.5.0.tar.gz
The gpg --verify command must report
  Primary key fingerprint: 44BC 9FD0 D688 EB00 7C4D  D029 E9CB DFC0 ABC0 A854


scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.5.0 git tag:
  https://dev.lovelyhq.com/libburnia/libburn/tree/release-1.5.0
(needs autotools >= 1.7 to apply command ./bootstrap)

and of the libburn-1.5.0 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.5.0.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:pkg-libburnia-de...@lists.alioth.debian.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

GNU xorriso 1.5.0 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.5.0
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.5.0.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: Add-on sessions with partition offset claimed too many blocks as
   size. Regression of version 1.4.8.

* Bug fix: Long Joliet names without dot were mangled with one character too
   many. Long Joliet names with leading dot were mangled one char
   too short.

* Bug fix: Reading beyond array end for HFS+ production caused SIGSEGV with
   FreeBSD 11 CLANG -O2. Thanks ASX of GhostBSD.

* Bug fix: SIGSEGV could happen if a track ended by reaching its fixed size
   while the track source still was willing to deliver bytes.
   Thanks to user swordragon.

* Bug fix: Multi-session emulation was not recognized with non-zero partition
   offset

* New -xattr mode "any" to process all xattr namespaces of local filesystem

* New -as mkisofs option --xattr-any

* New -as mkisofs options -uid and -gid


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread, libvolmgt
- NetBSD   : libc, libpthread
- OpenBSD  : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development , or libedit
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.5.0.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.5.0.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

Re: Could BD-RE disc come back to un-formatted state?

[Thomas Schmitt]

Hi,

sorry to the list: I forgot to Cc: it with my reply. But WF quoted it
completely, so i don't have to repost it here.

WF wrote:
> Currently I use dd to nullify the first 64KB to quickly
> clean the udf filesystem built on the BD-RE disc.

That's enough for ISO 9660 but not really for UDF. You need to hit the
"Anchor Volume Descriptors" at block 256, the last block of the medium,
and 256 blocks before the end. See
  http://wiki.osdev.org/UDF


> So the state switch of BD-RE disc is:
> blank -> formatted -> filesystem -> formatted

There is a distinction between hardware state "formatted medium" and the
data content state "formatted as filesystem".

Hardware formatting is a matter of the medium state as perceived by the
drive's firmware.
Optical media have two write access models, depending on the media type
and the hardware formatting state:

- CD-R, CD-RW, DVD-R, DVD+R, DVD-RW, and BD-R can be used unformatted
  in the sequential write model: The drive says where the burn program
  may begin writing and the burn program then writes block by block without
  trying to jump forth or back.

- CD-RW, DVD-RW, DVD-RAM, DVD+RW, BD-RE, and BD-R can be used formatted.
  Except for BD-R this implies the overwritable write model: The burn
  program can decide freely where to start writing (on DVD-RW in 32 KiB
  steps, on others in 2 KiB steps) and where to write next.
  This is near enogh to the normal block device model that the Linux kernel
  can offer "dd" a writable block device.
  BD-R can be formatted for sequential Defect Management or for
  Pseudo-Overwrite. growisofs formats to Pseudo-Overwrite by default.
 
What is "blanked medium" with an unformatted CD-RW or DVD-RW has no hardware
counterpart with overwritable media. Their "blank" rather means "yet unused
and in need of formatting".

Filesystem "formatting" is just a framework of readable data on the medium,
regardless whether hardware formatted or not. Beginning by a "superblock"
at some publicly defined position the filesystem driver software can then
interpret the data on the medium as directory tree, file content, or other
kinds of information.
So this kind of "formatting" can be erased by overwriting the superblocks,
the directory tree data, or the whole medium content.


> Since it cannot be deformatted back to blank state regularly, I have to use
> "lsblk -o FSTYPE" to classify the "formatted" and "filesystem" states.

If you want to erase all possibly readable file content on a BD-RE, then
you need to overwrite the entire medium with non-secret data. In the most
simple case:
  dd if=/dev/zero bs=1M of=/dev/sr0
This will hide any previous data from normal reader devices. But possibly
a forensic reader with special firmware could reconstruct the previous data.

Low security instructions for confidential data prescribe to overwrite the
medium 3 times with random numbers. Higher security demands can only be
fulfilled by physically destroying the medium.


> Your burner which could deformat BD-RE disc is really funny :-)

I needed some tries to find out that it was my attempt to read a CD
which destroyed its Blu-ray burn capability. To my luck it sits in an
USB box and can be de-powered without rebooting the system.

Interesting for your case:
The previously existing data were again readable after a "fast" formatting
run. So de-formatting a BD-RE is not really a privacy improvement.
(And it also did not remove the visible color contrast on the writable
 side of the medium.)


Have a nice day :)

Thomas

Announcing cdrskin-1.4.8

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.4.8 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread
or OpenBSD : libc, libpthread


Changes:

* Bug fix: Option -dummy did not affect writing by direct_write_amount=

* Refusing to write to BD-R if formatted to Pseudo Overwrite


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.4.8.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.4.8.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.4.8.tar.gz.sig cdrskin-1.4.8.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.4.8 git tag:
  https://dev.lovelyhq.com/libburnia/libburn/tree/release-1.4.8
(needs autotools >= 1.7 to apply command ./bootstrap)

and of the libburn-1.4.8 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.4.8.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:pkg-libburnia-de...@lists.alioth.debian.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

GNU xorriso 1.4.8 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.4.8
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.4.8.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: -as mkisofs -no-emul-boot without -boot-load-size defaulted to
   size 4, instead of full boot image size

* Bug fix: -read_fs "norock" did not prevent reading of root Rock Ridge info

* Bug fix: Mix of absolute and relative disk paths could cause SIGSEGV with
   pattern expansion

* Bug fix: --mbr-force-bootable did not get into effect with -append_partition

* Bug fix: Exit value of failed -mount command was reported as 0

* Bug fix: -boot_image actions "keep" and "patch" did not work any more.
   Regression by libisofs 1.4.4.

* New -find tests -maxdepth and -mindepth

* New commands -update_lxi and -update_li

* New -boot_image bootspec iso_mbr_part_type=

* New -as mkisofs option -iso_mbr_part_type

* New -as mkisofs option -eltorito-platform

* Properly refusing on Pseudo Overwritable formatted BD-R


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread, libvolmgt
- NetBSD   : libc, libpthread
- OpenBSD  : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development , or libedit
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.4.8.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.4.8.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

Re: BD-RE DL write failures

[Thomas Schmitt]

Hi,

> I suspect the good/slow items are again the media.

I assume that most of the "slow" ranges are due to relocated blocks.
Defect Management decided that the read quality was not good enough
and put a copy into the Spare Area, which is located at the inner rim
of the medium. So the laser head has to hope inwards and then back
outwards when it reaches the original invalidated position of the chunk.


> At the present time I am of the opinion that BD-RE is just too
> unreliable to continue working with it for data purposes.

The combination of BD-RE DL and your drives does not work well, indeed.
My own experience with single layer BD-RE is different. Not more than
two or three die per year. And i am using them daily.


> I might try another method of using the media like a tape drive by
> writing the tar file directly.  I think xorriso will do that from the
> man page.

It can put an ISO 9660 filesystem onto a tape, but that would be
hard to read.
In the old days i put tar or afio archives directly on QIC tapes.
It is quite painful to wait minutes until a particular file was
found and restored. Consider to use a more flexible tape archiver
like "dar".

In any case it is important that you practice restoring of particular
files before you decide for an archive format.


Have a nice day :)

Thomas

Re: BD-RE DL write failures

[Thomas Schmitt]

Hi,

> libburn : SORRY : SCSI error on read_10(297920,32): [3 11 05] Medium error. 
> L-EC uncorrectable error.

That's bad news for your hardware. A data chunk of 64 KiB did not match
its inner checksums. So the drive refuses to hand out these 64 KiB.

You would have to try the media in other drives to get an impression
whether it's the media or your drive which are to blame.


> Media checks :lba ,   size , quality
> Media region : 297824 , 32 , - unreadable
> Media region : 297920 , 32 , - unreadable
> Media region : 298048 , 32 , - unreadable

Just three unreadable chunks, quite near together. Not even 600 MiB away
from the medium start.

If it was necessary you could copy the damaged image to a data file on
hard disk (e.g. $HOME/bdre.img):

  xorriso -indev /dev/sr0 -check_media data_to="$HOME"/bdre.img --

You could even try several times or on several BD drives by having a
file bdre.map which records which blocks were read successfully and
which are yet missing in bdre.img:

   xorriso \
 -indev /dev/sr0 \
 -check_media data_to="$HOME"/bdre.img sector_map="$HOME"/bdre.map --

The already successfully read blocks will not be tried again.
One may carry medium, bdre.img, and bdre.map from computer to computer
in order to find a drive which can read the missing blocks.

The fact that command -indev did work shows that the directory tree is
not hit by the bad spots.
So, perfectly restored or not, the file bdre.img should be mountable
and the damaged tar archive should be readable. Dunno what tar will do
when it encounters 64 KiB of zeros in the middle of an archive where it
would expect some of its metadata.
This is a good opportunity to practice for a case of media which are ok
after recording but turn out to be slightly rotten much later.



But well, this is also the classic situation for Defect Management:
Some few bad spots on a large, elsewise good medium.

So you should try with one of the problematic media whether it works
slowly but correctly if you set

   -stream_recording "off"

It might be that Defect Management goes mad and lets the drive gnaw
endlessly not only on the bad spots above, but also on many other spots.
Or it might be that you have a rare case where Defect Management fulfills
the hopes which it stirs up.


Have a nice day :)

Thomas

Re: BD-RE DL write failures

[Thomas Schmitt]

Hi,

sorry, i did not react properly on this piece of info:

> The format, erase, and burn processes all complete normally with no
> issues or errors. When I mount and attempt to read the tar file it
> aborts with an error message.

Do you see related messages in the system logs ?

What happens if you let xorriso read the medium:

  xorriso -indev /dev/sr0 -check_media --


Have a nice day :)

Thomas

Re: BD-RE DL write failures

[Thomas Schmitt]

Hi,

> The media was labeled "for Video".  So I found some Maxell that was
> labeled "for Data"

If those "for Video" were more expensive than the others, then you probably
paid royalties to the movie industry. We had such a situation with special
CD-R media for audio recording. Some living room CD recorders did not accept
the less expensive normal CD-R.

In general, there is no difference in BD and DVD recording between video
and data. It's just a matter of filesystem (video prescribes UDF),
particular files, and possibly cryptographic information for content
authentication.

Other than with DVD+R DL, it is not possible to chose the layer jump
address with multi-layer BD-R[E]. Afaik, there is few way to distinguish
a single layer BD-RE from a dual layer BD-RE other than by their size.
So i would not expect that the dual layer BD-RE need any extra treatment.


> Two have worked very well every time
> for my 26 GByte tar file.  The other three discs have the same issue as
> the earlier media.
> ...
> Any suggestion on how to get a reliable burn?

What's the symptoms exactly ?
What messages do you get from xorriso ?

-

Preliminary thoughts. They might become useless when more info arrives.

> /usr/bin/xorriso -stream_recording on

Did you try with -stream_recording "off" ?
That will be darn slow. If it clonks and goes to 0.0x speed with only
a 0.1x every fifth pacifier messages, then Spare Area blocks get
employed. (Normally you get a medium error some time later.)


> -speed "-1"

That's equivalent to -speed "min". Just for the records.


> I also added the -speed "-1" option to attempt to
> lower the write speed but it did not have any effect

BD-RE as overwritable media do not offer much choice of write speed and
normally do not obey write speed settings, especially if you mark the
data as urgent-to-write by -stream_recording "on".


Have a nice day :)

Thomas

Re: cdwrite from source

[Thomas Schmitt]

Hi,

Bob wrote:
> how do I compile cdwrite from source?

That's an unusual question. This list is named "cdwrite". But since i
subscribed more than a decade ago, it was always about younger programs
cdrecord, growisofs, cdrskin, xorriso.

Not what you probably look for:
  https://www.slackbuilds.org/repository/14.1/system/cdwrite/
(Scripts from this century, using other backend programs.)

This here looks sufficiently antique:
  https://www.kokkonen.net/tjko/src/cdwrite/
The complete prescription would then be
  wget https://www.kokkonen.net/tjko/src/cdwrite/cdwrite-2.0.tar.gz
  tar xf cdwrite-2.0.tar.gz
  cd cdwrite-2.0 
  ... apply patches for SGI IRIX and a Teac burner ... 
  make

The text refers to cdrecord as successor and mentions that the cdwrite
program is not yet suitable for Linux.
I would not try to use the programs from that tarball.

My advise is to decide for one of the above younger backends,
which are all 10 years old at least. 
Ask here if you have trouble with building or using.


Have a nice day :)

Thomas

Announcing cdrskin-1.4.6

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.4.6 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread
or OpenBSD : libc, libpthread


Changes:

* Bug fix: SAO CD could be perceived 2 blocks to short.
   Regression in 1.4.4 by rev 5672.

* Now operating optical drives on OpenBSD. Thanks to SASANO Takayoshi.

* New cdrskin option use_immed_bit=


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.4.6.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.4.6.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.4.6.tar.gz.sig cdrskin-1.4.6.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.4.6 SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.4.6
(needs autotools >= 1.7 to apply command ./bootstrap)

and of the libburn-1.4.6 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.4.6.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:pkg-libburnia-de...@lists.alioth.debian.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

GNU xorriso 1.4.6 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.4.6
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.4.6.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: SIGSEGV by NULL when a data file was larger than ISO level allows.

* Bug fix: SAO CD could be perceived 2 blocks to short.
   Regression in 1.4.4 by rev 5672.

* Bug fix: The default setting of -compliance did not apply rec_mtime to
   Joliet and ISO:1999. mkisofs emulation was not affected by this bug.

* Bug fix: -file_size_limit did not increase ISO level if necessary.
   Thanks to Mattias Schlenker.

* Bug fix: Interpretation of 17 digit timestamps was wrong.

* Now operating optical drives on OpenBSD. Thanks to SASANO Takayoshi.

* New command -use_immed_bit, new -as cdrecord option use_immed_bit=

* Made several pseudo-random ids reproducible by overriding volume modification
  time.

* New -volume_date mode "all_file_dates"

* New -as mkisofs option --set_all_file_dates

* New bootspec "gpt_disk_guid=", new -as mkisofs option --gpt_disk_guid

* New -report_system_area modes "gpt_disk_guid", "make_guid"

* New -find action "set_to_mtime"

* New environment variable SOURCE_DATE_EPOCH as of reproducible-builds.org.


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread, libvolmgt
- NetBSD   : libc, libpthread
- OpenBSD  : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development , or libedit
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.4.6.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.4.6.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

Announcing cdrskin-1.4.4

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.4.4 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread


Changes:

* Bug fix: Option drive_scsi_dev_family=sg did not convert /dev/sr* to /dev/sg*

* Bug fix: burn_make_input_sheet_v07t() falsly recognized double byte encoding.
   Affected cdrskin option: cdtext_to_v07t=

* Bug fix: Double free at end of run if burn_write_opts_set_leadin_text() is
   used. Affected cdrskin option: textfile=

* Bug fix: DVD book type of DVD+RW DL and DVD+R DL was reported wrong.
   Thanks to Etienne Bergeron.


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.4.4.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.4.4.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.4.4.tar.gz.sig cdrskin-1.4.4.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.4.4 SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.4.4
(needs autotools >= 1.7 to apply command ./bootstrap)

and of the libburn-1.4.4 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.4.4.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:pkg-libburnia-de...@lists.alioth.debian.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

GNU xorriso 1.4.4 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.4.4
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.4.4.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: -as mkisofs did not unescape "\=" in the source part of pathspecs

* Bug fix: -boot_image "any" "system_area=/dev/zero" did not zeroize loaded
   data

* Bug fix: -pathspecs "on" did not properly handle "\\="

* Bug fix: HFS+ production could cause MBR partition of type 0xEE without GPT

* Bug fix: HFS+ directories could announce more children than they actually have

* Bug fix: The HFS+ filesystem was not marked by in GPT of GRUB2 hybrid layout

* Bug fix: When reading an ISO filesystem, the presence of
   --protective-msdos-label was not recognized if a partition is
   appended

* Bug fix: xorrisofs option --protective-msdos-label did not work if no
   system area data were given by option -G or alike

* Bug fix: -modesty_on_drive properties timeout_sec, min_usec, max_usec
   read wrong numbers from the parameter text

* Letting -as mkisofs --norock revoke the special effect of -r

* Letting -blank on overwritable media invalidate UDF extended descriptors

* New -pathspecs mode "as_mkisofs"

* New -boot_image setting mbr_force_bootable=, -as mkisofs --mbr-force-bootable

* New -boot_image bootspecs appended_part_as=apm, part_like_isohybrid=on

* New -as mkisofs options -appended_part_as_apm, -part_like_isohybrid

* New command -scsi_dev_family, new -as cdrecord option drive_scsi_dev_family=


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread, libvolmgt
- NetBSD   : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development , or libedit
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.4.4.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.4.4.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

Bug fix release cdrskin-1.4.2.pl01

[Thomas Schmitt]

Hi,

it turned out that cdrskin-1.4.2 does not work with track input from stdin,
e.g. from a pipe fed by genisoimage. The bug was newly introduced by
cdrskin-1.4.2. Its fix is in
  http://libburnia-project.org/changeset/5653/libburn/trunk/cdrskin/cdrskin.c

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread


Changes:

* Bug fix: cdrskin "failed to attach fifo" when burning from stdin.
   Regression of 1.4.2, rev 5522.


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.4.2.pl01.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.4.2.pl01.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.4.2.pl01.tar.gz.sig cdrskin-1.4.2.pl01.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.4.2.pl01 SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.4.2.pl01
(needs autotools >= 1.7 to apply command ./bootstrap)

and of the libburn-1.4.2.pl01 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.4.2.pl01.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:pkg-libburnia-de...@lists.alioth.debian.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

Announcing cdrskin-1.4.2

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.4.2 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread


Changes:

* Bug fix: Endless loop if transport error occurs while waiting for drive ready

* New -toc line "Drive id" tells the drive's individual serial number


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.4.2.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.4.2.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.4.2.tar.gz.sig cdrskin-1.4.2.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.4.2 SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.4.2
(needs autotools >= 1.7 to apply command ./bootstrap)

and of the libburn-1.4.2 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.4.2.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:pkg-libburnia-de...@lists.alioth.debian.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

GNU xorriso 1.4.2 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.4.2
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.4.2.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: -backslash_codes "on" did not work outside quotes
   and with showing "\r"

* Bug fix: zisofs compression caused SIGSEGV (by reading) with files larger
   than 524160 KiB.

* Bug fix: Names read from Joliet tree where stripped of trailing ";1"

* Bug fix: Media summary session count of blank and closed media was short by 1

* Bug fix: Endless loop if transport error occurs while waiting for drive ready

* Now sorting the data file content extents by ECMA-119 tree, rather than
  by the red-black tree which shall consolidate files with identical
  source object.

* New options with isoburn_ropt_set_extensions(): isoburn_ropt_map_*

* New command -modesty_on_drive,
  new -as cdrecord -immed, minbuf=, modesty_on_drive=

* New command -ecma119_map

* New command -read_fs

* New -boot_image action "replay"

* New command -file_name_limit, -as mkisofs -file_name_limit

* New -find test -name_limit_blocker.


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread, libvolmgt
- NetBSD   : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development , or libedit
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at
your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.4.2.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.4.2.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas

GNU xorriso 1.4.0 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.4.0
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.4.0.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: -dev or -indev of medium with non-ISO data caused SIGSEGV by NULL

* Bug fix: A SIGSEGV could happen when loading a faulty ISO filesystem.
   Debian bug 774152. Thanks to Jakub Wilk.

* Bug fix: Rock Ridge Continuation Area could be produced crossing a block
   boundary. This is heavily disliked by the Linux kernel and spoils
   the representation of directories which contain many symbolic links.

* Bug fix: If iso_write_opts_set_hardlinks() enabled automatic inode numbers,
   then they did not get into effect with nodes were zisofs decoder
   filters got attached during the image load process.

* Bug fix: The header indicator of the last El Torito catalog section header
   was set to 0x90 rather than 0x91 if more than one boot image is in
   that section.

* Bug fix: Only 128 bytes of an emerging GPT header block were zeroized.

* Bug fix: -report_system_area did not show GPT partitions of size 0.

* Bug fix: A zero sized GPT partition was marked after the last appended
   GPT partition.

* Improved handling of cylinder alignment if the resulting image size is not
  divisible by 2048. Old behavior was to not align. New is to pad up by a
  few blocks of 512 bytes.

* Increased default weight of El Torito boot catalog to 1 billion.

* New -find action show_stream_id

* Optional libisofs interval reader with -append_partition and System Area
  commands.

* New -boot_image bootspec appended_part_as=,
  new -as mkisofs option -appended_part_as_gpt

* New -report_system_area formats cmd and as_mkisofs


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread, libvolmgt
- NetBSD   : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development , or libedit
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at
your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.4.0.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.4.0.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/14575570226335593...@scdbackup.webframe.org

Announcing cdrskin-1.4.0

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.4.0 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread


Changes:

* Bug fix: Double free with cdrskin -vvv.
   Introduced with rev 5065, version 1.3.1


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.4.0.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.4.0.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.4.0.tar.gz.sig cdrskin-1.4.0.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.4.0 SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.4.0
(needs autotools = 1.7 to apply command ./bootstrap)

and of the libburn-1.4.0 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.4.0.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/9720570225974572...@scdbackup.webframe.org

Re: Problem with growisofs -- cannot write multisession DVDs without ejecting and reloading tray

[Thomas Schmitt]

Hi,

 Can xorriso toggle the drive tray?  That is, is there a xorriso equivalent
 of eject -T?

It tries to load the tray when it aquires a drive.
(SCSI command START/STOP UNIT with Start bit and Load/Eject bit set.)

Whether the drive obeys depends on having a drive tray motor.
If eject -T works, then
  xorriso ... -dev /dev/sr0 ...
is supposed to work, too.


 I was only curious, since the status doesn't seem to
 report whether the drive is open or closed.

If
  -status -indev
reports a drive address, then there is an ISO filesystem
loaded or a blank medium aquired. Thus the tray must be in
and either -dev or -indev was used to aquire the drive.

With -outdev it should be possible to have a drive aquired
which has left its tray open. (I have no laptop drive which
would have no tray motor. But empty drives stay aquired with
-outdev.)

You can do your first session on blank medium by -dev.
My example in a previous mail uses -outdev to assert that
the medium is blank. (xorriso refuses to add a session to
a non-blank medium from which it did not load ISO meta data.)


 then I will stop clogging up the list:

This list is really not clogged by on-topic conversations.
Be invited to ask if you got more questions.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/3676569425563460...@scdbackup.webframe.org

Re: Problem with growisofs -- cannot write multisession DVDs without ejecting and reloading tray

[Thomas Schmitt]

Hi,

  The new session adds a new superblock,

 I was thinking that the entire DVD had one
 superblock at the beginning, and that couldn't be right, because how would
 it get updated?

This is the situation with overwritable media:
DVD+RW, DVD-RAM, BD-RE, formatted DVD-RW, formatted CD-RW,
data files, Linux block devices.

The new session gets written like with sequential media
(CD-R, CD-RW, DVD-R, DVD+R, BD-R, unformatted DVD-RW)
but the superblock at block offset 0 gets overwritten to
lead the mounters to the youngest session.
xorriso by default creates the superblock of the first
session at offset 32 and a copy at offset 0. This way
the superblock at offset 32 survives the updates at
offset 0 when more sessions get burned.


 I am trying to figure out if I can close a DVD without writing a new file to
 it.

Interesting use case. I don't think that my stuff can do
this. But i dimly remember that growisofs ...
man 1 growisofs, EXAMPLES:

To finalize the multi-session DVD maintaining maximum compatibility:
growisofs -M /dev/dvd=/dev/zero

(I never tried this.)


 xorriso -dev /dev/sr1 -status short

Command -status will tell you the current settings of various
xorriso commands, but nearly nothing about the medium state.

The info about the number of sessions is put out on stderr
after a drive was aquired by -dev, -indev, or -outdev.

  $ xorriso -outdev /dev/sr2  21 | grep '^Media summary:'
  Media summary: 129 sessions, 8597504 data blocks, 16.4g data, 7074m free

The command -toc puts out the line Media summary:, too.
Its output goes to stdout. Its line Media blocks : gives
exact sizes counted in units of 2048 bytes.

  $ toc=$(xorriso -outdev /dev/sr2 -toc 2/dev/null)
  $ echo $toc | grep '^Media blocks :'
  Media blocks : 8597504 readable , 3621888 writable , 12219392 overall
  $ echo $toc | grep '^Media summary:'
  Media summary: 129 sessions, 8597504 data blocks, 16.4g data, 7074m free


 is there a way to get the number of session
 left for the medium?  Short of manually subtracting the number of sessions
 on the disk from 99, that is.

Not yet. The numbers 99 and 153 are theoretical values.
The real number of remaining sessions depends on the size of
those sessions and on the gaps between sessions.

With BD-R there is no limit announced in the MMC specs.
My oldest BD burner can put more than 300 on the medium
before it fails quite miserably. My younger ones throw
error after about 120 to 140 sessions. (I am awaiting the
refusal of my current backup BD-R every day.)
For professional purposes i would impose a limit of 100
sessions and then just begin with a new medium.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/30792569470933569...@scdbackup.webframe.org

Re: Problem with growisofs -- cannot write multisession DVDs without ejecting and reloading tray

[Thomas Schmitt]

Hi,

  OpenSolaris snv 134 always mounts the youngest session.

 You'll have to forgive me, but I don't know what this means.  Would that
 mean that only the last files written can be seen, or all of them?

You see all files which you added (and did not delete later).

The capability to access older states is interesting with
incremental backups.

ISO 9660 multi-session works like this:

The new session adds a new superblock, a new complete directory
tree, and the content of data files which were newly added
or overwritten by the session.

The older superblocks and directory trees still exist on the
disc. They may point to older versions of files which got
replaced by other content in further sessions, and they may
contain files which were deleted from the directory tree
of the younger sessions.

Operating systems by default use the youngest superblock
and directory tree for mounting.

But as said, mounting older sessions imight be desirable with
incremental backups. E.g. if i want to mount the backup state
of three days ago, i put in my backup BD-R and do

  xorriso -indev /dev/sr2 -toc

which tells me

  TOC layout   : Idx ,  sbsector ,   Size , Volume Id
  ISO session  :   1 , 0 ,   1461973s , HOME_2015_01_05_130954
  ISO session  :   2 ,   1462144 , 53613s , HOME_2015_01_06_114520
  ...
  ISO session  : 126 ,   8364224 , 54847s , HOME_2015_05_10_113721
  ISO session  : 127 ,   8419232 , 62170s , HOME_2015_05_11_120517
  ISO session  : 128 ,   8481568 , 63170s , HOME_2015_05_12_135346
  Media summary: 128 sessions, 8544896 data blocks, 16.3g data, 7177m free

If i then execute (on Linux)

  mount -o sbsector=8364224 /dev/sr2 /mnt/iso

i get to see the backup state of may 10 2015, 11:37:21.

There is some convenience built in. The run

  xorriso -mount_cmd /dev/sr2 volid '*_2015_05_10_*' /mnt/iso

on Linux makes this proposal of a mount command:

  mount -t iso9660 -o nodev,noexec,nosuid,ro,sbsector=8364224 '/dev/sr2' 
'/mnt/iso'

On FreeBSD the proposal would rather look like
  mount_cd9660 -o noexec,nosuid -s 8364224 '/dev/cd1' '/mnt/iso'

A privileged user may also do

  xorriso -osirrox on -mount /dev/sr2 volid '*_2015_05_10_*' /mnt/iso

and have the proposed command executed directly by xorriso.
(One still has to umount manually, when done.)

My backup sessions got their volume ids with time stamp
by xorriso command

  -volid HOME_$(date '+%Y_%m_%d_%H%M%S')

when the backups were made. (See man page example
Incremental backup of a few directory trees.)





-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/21026569886338335...@scdbackup.webframe.org

Re: Problem with growisofs -- cannot write multisession DVDs without ejecting and reloading tray

[Thomas Schmitt]

Hi,

 xorriso

 Chorizo?  Shore-Isso?  Zoar-Eyesoh?

X/Open on Rock Ridge enhanced ISO 9660 = xorriso 

I'm german and pronounce it like english ksorreeso.
But actually one has just to know how to write its name. :))


 But can it display the contents of the not-mounted filesystem without using
 DVD+RW? 

If you want it lengthy and complete:

  xorriso -indev /dev/sr0 -find / -exec lsdl --

If you know what you look for

  xorriso -indev /dev/sr0 -lsl /my/file/or/directory '/another/x*' --

Or if you like a dialog session:

  xorriso -dialog on

then put in command lines like

  -dev /dev/sr0
  -lsl / --
  -dus /my/directory --
  -tell_media_space
  -end

or manipulate the ISO for adding another session

  -rm_r /do/not/want/this/tree/any/more --
  -mv /old/path /newly/invented/path --
  -map /tree/from/disk /tree/in/iso
  -for_backup

cause writing of the new session by

  -commit

or revoke the changes by

  -rollback_end


Note that these are not options, which one can submit
in any sequence, but rather commands which get executed
in the sequence they are given. I.e. you first need
to read the metadata by -indev before you can inquire
them by -find.
Commands with a variable number of arguments get their
end marked by '--', so that more than one command can be
witten into one line. Line end is equivalent to '--',
though. You may as well end any command by '--'. Surplus
'--' get ignored. Command -list_delimiter can choose
another delimiter string instead of '--'.

man xorriso(1) has 4730 lines which hopefully explain
most of its properties. Users are advised to start
with the EXAMPLES section.


 Yeah, we have been accepting a waste of 200MB on the first session as a fact
 of life. 

The 200 MB probably are due to a decision of the drive
which believes that the first session needs to be larger
than the few KB which you did put in. (I know of a 1 GB
minimum size for DVD-R DAO. But your run was Incremental,
rather than DAO.)

If the use case needs write-once media:
DVD+R waste only 4 MB per session.


 Would the kernel developers take this particular problem more seriously if
 more people complained about it?

The place to complain would be LKML (Linux Kernel Mailing List).
Be aware that the language there can be very direct (cough)
and that nobody there waited for a userlander who cannot
fix his kernel problems by own means.
(We userlanders better solve our problems were we live.)


  Solaris has no option to mount an older session.

 That is curious to me, since as I said, the way I proved this wasn't a
 hardware problem was by showing that it worked on Solaris 10.

OpenSolaris snv 134 always mounts the youngest session.
(There are traces in growisofs that Solaris once mounted
 always the first session.)
Linux (by mount -o sbsector=) and FreeBSD (by mount -s) offer an
opportunity to mount any of the sessions if you know their start
block (e.g. from xorriso command -toc). 

Solaris man mount(8) does not offer such an option.
I peeked into the OpenSolaris kernel and saw no means to send
down a start block parameter to the function which chooses
the superblock address for mounting. 


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/23548569674030165...@scdbackup.webframe.org

Re: Problem with growisofs -- cannot write multisession DVDs without ejecting and reloading tray

[Thomas Schmitt]

Hi,

the problem you describe is caused by the Linux block
device driver not being aware of the changes on the DVD
which were made via the Linux generic SCSI driver.
growisofs normally fights this by its finger biting
unload-reload cycle, which forces the block device
driver to re-assess the medium.
dvd+rw-mediainfo uses the SCSI driver and thus shows
you the current media state even without reloading.

There is not much hope for a remedy about mount(8)
unless Linux offers an opportunity to re-assess the
medium without loading. growisofs.c shows traces of
Andy's fight against the kernel's ignorance. E.g.
 * - Linux: deploy BLKFLSBUF to avoid media reloads when possible;

Another negative effect of this situation is that
growisofs employs mkisofs (or a clone or an emulation)
which reads the disc by the block device driver and
thus can get to see outdated buffered disc state.
But other than with mount(8) the user space program has
a choice between the two rivaling drivers.

libisoburn resp. its application xorriso read via the
SCSI driver and thus get to see the current disc content.
content.

So xorriso can do multi-session without reload.
First session (like growisofs -Z):

  xorriso -outdev /dev/sr0 -blank as_needed -follow link \
  -add file1file1file1_REDHAT.txt file2file2file2_REDHAT.txt \
   file3file3file3_REDHAT.txt --

Further session (like growisofs -M):

  xorriso -dev /dev/sr0 -follow link \
  -add file4file4file4_REDHAT.txt file5file5file5_REDHAT.txt \
   file6file6file6_REDHAT.txt --


As said, the problem of mount(8) remains, because the
ISO 9660 filesystem driver relies on the block device
driver.
xorriso can copy files out of not mounted ISO filesystems

  xorriso -osirrox on -indev /dev/sr0 \
  -extract /file4file4file4_REDHAT.txt \
   $HOME/file4file4file4_REDHAT.txt \
  -extract /some/directory/tree \
   $HOME/tree_from_iso

-
Proposal for mount(8) and multi-session by different media:

If you can use DVD+RW, then it would be possible to
perform all write and read traffic by the block device
driver. DVD-R and DVD+R cannot be written that way.

To let xorriso use the block device driver, prepend
stdio: to the drive address with above xorriso runs:

  xorriso -outdev stdio:/dev/sr0 ...

resp.

  xorriso -dev stdio:/dev/sr0 ...

xorriso will emulate a table-of-content and thus allow
to access the older sessions by Linux mount(8) option
-o sbsector=$block_address.
Its own read facility can be directed to older sessions
by
  -load session $number -indev ...
or
  -load sbsector $block_number -indev ...
or
  -load volid $search_pattern -indev ...

With small sessions, DVD+RW have a substantial capacity
advantage over DVD-R, because the latter put gaps of
more than 10 MiB between sessions. The waste after the
first session is even larger. In your last dvd+rw-mediainfo
output one can read:
  Track Start Address:   0*2KB
  Track Size:65264*2KB
  Track Start Address:   93952*2KB
  Track Size:192*2KB
  Next Writable Address: 100304*2KB
Multi-session emulation of libisoburn on DVD+RW only
pads up to the next full multiple of 64 KiB.

The number of sessions on DVD-R is restricted to 99,
on DVD+R the limit is 153.
On DVD+RW, the number is only limited by the data
storage capacity of the medium. But dvd+rw-mediainfo
will show only one session, because the hardware has
only one single logical track.
Use 

  xorriso -indev /dev/sr0 -toc 

to get a list of ISO 9660 sessions.

-
(Rant zone)

 Am I missing something?

Not you. But the Linux kernel developer community does.
It offers drivers for about any exotic device, but
it does not care for coordination between driver
levels or for a decent performance of the SCSI driver
when more than one burn run is active.

Said that, i have to state that the other free operating
systems show no better overall quality with handling
optical media.
Their ISO 9660 filesystem drivers are all inferior to Linux.
Solaris has no option to mount an older session. The
BSDs are unable to do multi-session above 4 GiB. Solaris
and BSDs cannot properly represent in a mounted ISO 9660
files of size 4 GiB or larger.
Not to speak of the stability of the USB driver when
a drive gets powered off or unplugged.

So i stay with Linux despite some frustration.
(The CD TAO read-ahead bug is about 20 years old now.
 systemd adds a new layer of interference without
 solving the old problem of uncoordinated drivers.)

(End of rant zone)
-


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/365256893496135...@scdbackup.webframe.org

Re: BD-R DL burning from ISO

[Thomas Schmitt]

Hi,

 Yes. In a mean time I got several conformations that it's K3b's fault and
 that the code has not been maintained for a long time.

Obviously it is more appealing to start GUI projects
rather than to keep them up to date.


 I'll try xfburn. Can you comment on stability and feature completeness of 
 libburn? I think I never used any app that's built upon it.

I am the current developer of the libraries.
Also developer of cdrskin and xorriso.
I do not use anything else for burning and every day
i risk my personal multi-session backups by expanding
them by the development version of xorriso.
(I have more than one backup per day. But it would hurt
my pride to lose a BD-RE with 530 days of recoverable
history.)


 Yes, my device path is /dev/sr0, though I'm trying to burn an ISO image, not
 udf one, but I suppose it's the same.

Whatever you want to burn.

 I've read about BD's defect management and it seems like a smart feature

Your mileage may vary ...

 but I wonder would my standalone (Panasonic) BD player be able to read defect 
 managed disk and could I experience so hiccups during movie play because it?

The hickup might then be out of different reasons, if
the player does not read ahead by some dozen MB.
If a defect sector was replaced, then the substitute
is located at the inner rim of the disc. So depending
on the current read position, the head has to make a
long move. And maybe back and forth quite often.

I use Defect Management for the first 50 MB of single
session on BD-RE because that's usually enough to take
the ISO 9660 directory tree of a 23 GB backup.
And i use it for incremental backups which normally
write only 100+ MB per session.
On the wide range i prefer 2x speed and post-burn
checkreading over Defect Management.

With 6x BD-R it makes few difference because my local
filesystem cannot collect data fast enough from single
to feed more than 3x effective speed.
With an image file as input, this would be different.
(To my personal experience, BD-R with Defect Management
fail at least as often as those without. But the
statistical base is not very large.)


 I didn't get that part - does growisofs have broaken
 BD defect management?

The upstream version has problems caused by its habit
to automatically format yet unformatted BD-R. After
formatting, it still has a flag set that indicates
unformatted BD-R. This flag causes an inappropriate
SCSI command to be emitted at the end of the burn run
  https://bugs.launchpad.net/ubuntu/+source/dvd+rw-tools/+bug/1113679
This is on its way to be fixed in the distros.

Next problem is that it does the check for predictable
medium overflow before formatting, using the unformatted
size. If the input size is larger than the formatted
size but smaller than unformatted, then the burn on
automatically formatted medium will end badly after
having used up the whole medium.
  https://bugs.launchpad.net/ubuntu/+source/dvd+rw-tools/+bug/1424215

But as stated, my growisofs proposals circumvent the
situation. Either by presenting an already formatted
BD-R, or by telling growisofs not to format.


http://www.gnu.org/software/xorriso/xorriso-tcltk-screen.gif
 Wow! :) That's great! Didn't know about that program. Thanks!

It is mainly intended to demonstrate the capability
of xorriso to serve graphical frontends as dialog partner
and not as child worker.
I.e. the frontend does the presentation and xorriso
does the ISO 9660 and MMC stuff. No duplicate file trees
in GUI and backend. No hald or udev which tell nonsense
about drive and medium.

I used Tcl/Tk because it is easy, quite incapable of
serious computing, and lightweight.
My hope is that some GUI programmer uses a real
programming language and a fancy look+feel.
But currently there are a lot of half-dead frontends
lying around.

Clicking right mouse button on button Burn image file:
yields a pop-up window with:

  The Burn image file: button executes command -as cdrecord to
  burn a data file from hard disk onto the output drive.
  The address of the disk file is taken from the neighboring text field.
  
  If you do not plan to append further data to the medium, then consider
  to enable the Close switch.
  
  No input drive may be aquired. (Delete all characters from the field
  Input drive/image and hit Return to give up the input drive.)
  
  The medium in the drive must be blank.
  (It is well possible to burn image files to appendable media. But the
  image needs to be prepared for the address offset. Who can do that can
  as well use one of the command line tools for burning the result. E.g.
xorriso -as cdrecord -v dev=/dev/sr0 -multi stream_recording=32s image.iso
  )

It is worth to read man xorriso about xorriso commands
mentioned in the help texts of xorriso-tcltk.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: 

Re: BD-R DL burning from ISO

[Thomas Schmitt]

Hi,

firstly:
Your trouble has nothing to do with image content.
You may burn what you want as long as it fits into
the number of 2048 blocks, which the medium offers.

It might be that GUI frontends are still not ready
for BD media. The halfways modern backends (growisofs,
cdrecord, libburn) support them.

I helped to beef up xfburn version 0.5.2 so that
it accepts BD media and makes use of the according
libburn capabilities.

On the command line there are:

  dvd+rw-format /dev/sr0
  growisofs -Z /dev/sr0=$HOME/my_image.udf

or

  growisofs -use-the-force-luke=spare:none -Z /dev/sr0=$HOME/my_image.udf

or

  cdrecord -v dev=/dev/sr0 $HOME/my_image.udf

or

  cdrskin -v dev=/dev/sr0 $HOME/my_image.udf

or

  xorriso -as cdrecord -v dev=/dev/sr0 $HOME/my_image.udf


The drive address is assumed as /dev/sr0 here.
You may get a list of accessible optical drives by

  xorriso -devices

which might say something like

  0  -dev '/dev/sr0' rwrw-- :  'TSSTcorp' 'CDDVDW SH-S203B' 
  1  -dev '/dev/sr1' rwrw-- :  'HL-DT-ST' 'BD-RE BH16NS40' 

(I.e. i'd better use /dev/sr1 for BD burning.)


If you want full nominal speed on formatted BD, use
cdrskin or xorriso -as cdrecord option
   stream_recording=on
No checkreading and no bad block replacement will happen
then.

If you want formatted BD-R (for slow checkreading):

  dvd+rw-format /dev/sr0

or

  cdrskin -v dev=/dev/sr0 blank=format_defectmgt

or

  xorriso -outdev /dev/sr0 -format as_needed

These will get you the default size. There are options to
vary the formatted size, too.


 I'm trying to understand where is the problem and should this be
 submitted as a bug report or a feature request and to whom.

The problem seems with k3b.

 Couldn't some program simply read raw data in the ISO image and then
 burn it to a media bit by bit, or things just don't work that way?

Well, we have to send data in chunks of at least 2048
bytes, better of 64 KiB. The communications protocol
between burn (backend) program and drive is defined
in SCSI/MMC. BD are mentioned since MMC revision 5.


 It is also stated on
 dvd+rw-tools' web page that growisofs depends on cdrtools, namely
 mkisofs, 

Only on mkisofs, not on cdrecord.
growisofs is its own burn backend.
Hard to surpass with DVD and with only a little
flaw about automatic formatting of BD-R. (Above
examples work around it.)

 I speculate that in this case I don't need mkisofs because
 I already have (UDF 2.5) file system in the image and I'm merely
 trying to burn it on a BD-R DL disk. Right?

Yes.

 K3b claims that it supports Blu-ray

Then your problem should be considered a bug.
At least if you manage to burn by any of the above
command line examples.

 who gets the job done and how? :S

Choose one of the programs mentioned above.
The command liners have nearly no dependencies.
xfburn might drag in half of Xfce.
(I can offer a frontend demo named xorriso-tcltk
  http://www.gnu.org/software/xorriso/xorriso-tcltk-screen.gif
which depends only on Tcl/Tk.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/1390554250794553...@scdbackup.webframe.org

GNU xorriso 1.3.8 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.3.8
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.3.8.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: -boot_image grub grub2_mbr= did not work
   (but -as mkisofs --grub2-mbr did work)

* Bug fix: -boot_image grub2_mbr=  prevented -boot_image partition_table=on

* Bug fix: libburn: A final fsync(2) was performed with stdio drives,
even if -stdio_sync was set to off.

* Bug fix: libburn: Wrong stack usage caused SIGBUS on sparc when compiled
by gcc -O2

* Bug fix: -blank force:all on DVD+RW had no effect

* Enabled use of libedit as alternative to libreadline

* Enabled recording and restoring of extattr on NetBSD

* New bootspecs hppa_*, new -as mkisofs options -hppa-* for HP-PA via PALO

* New -find pseudo tests -use_pattern , -or_use_pattern

* New -find action report_sections

* New command -concat

* New commands -report_system_area and -report_el_torito

License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread
- NetBSD   : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development , or libedit
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at
your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.3.8.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.3.8.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/621765508132467...@scdbackup.webframe.org

Announcing cdrskin-1.3.8

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.3.8 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread


Changes:

* Bug fix: Minimum drive buffer fill was measured by cdrskin before
   the buffer could get full

* Bug fix: A failed MMC BLANK command did not cause error indication
   by libburn


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.3.8.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.3.8.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.3.8.tar.gz.sig cdrskin-1.3.8.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.3.8 SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.3.8
(needs autotools = 1.7 to apply command ./bootstrap)

and of the libburn-1.3.8 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.3.8.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/1210655081389331...@scdbackup.webframe.org

What to use as replacement for Freshmeat ?

[Thomas Schmitt]

Hi,

i just learned that Freshmeat (meanwhile freecode.com) has closed
the shop. It used to be a channel to inform about new releases of
libburnia and xorriso.
The libburnia announcement mailing list is down too (because of
domain squatting) so i run out of low-traffic channels for
announcements.

Any proposals where one could establish a new announcement
channel to which interested packagers could subscribe ?
Are there public sites left like Freshmeat was ?


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/22485655078335575...@scdbackup.webframe.org

Re: What to use as replacement for Freshmeat ?

[Thomas Schmitt]

Hi,

dale.joll...@yahoo.com:
 Is GitHub viable?

I could not yet spot whether it has an announcement service
to which distro packagers could subscribe.

I'd need something like a mailing list which drops any
input other than mine. No spam, no support requests or bug
reports, just release announcements.

The advantage of Freshmeat/Freecode was that the procedure
of subscription and unsubscription was a black box to me.
I could not spam people and had not to recover their lost
passwords. Some 40+ subscribers existed, last time i looked.

Is anything positive or negative known about freelists.org ?


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/29622655085634733...@scdbackup.webframe.org

Re: Write on BD-R/BD-RE

[Thomas Schmitt]

Hi,

 Hi, I'm new to this project

We aren't actually a project here. Rather a chat room.


 On the CD-R/RW and DVD-R/RW part, I guess it's almost everything ok,
 but on BD-R/RE I still don't know exactly what do I have to do.
 So I started to search some open source BD burners to see if I could
 know how to do it, and I've found this list.

You did not mention DVD+R, DVD+RW, and DVD-RAM.

Actually BD-R can be handled much like DVD+R.

BD-RE is much like DVD-RAM. Similar to DVD+RW or formatted DVD-RW.


 So, basically I came to ask if anyone of you guys could give me and
 overall view on how the writing on BD works.

My knowledge on SCSI/MMC level is recorded in
  http://libburnia-project.org/browser/libburn/trunk/doc/cookbook.txt

See chapters
  - Overwriteable DVD Cookbook (DVD-RAM, DVD+RW, DVD-RW, BD-RE)
  - BD-R Cookbook

You will need copies of MMC-5 and SPC-3. There are drafts around in
the internet. Else you can buy them as PDF for 60 USD each from INCITS.
(A few years ago the drafts were free. Later one could buy final
 versions for 30 USD. Now they want 60. Grrr.)

Easiest hands-on example are the programs of dvd+rw-tools:
growisofs, dvd+rw-format, dvd+rw-mediainfo.
(Beware of the BD-R bug, which bites if you submit a blank unformatted
 BD-R to growisofs. It will format it but still have memorized that
 it is unformatted. So an inappropriate MMC command will be sent at
 the end of writing.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/24412658403650886...@scdbackup.webframe.org

Re: Long term archiving - which brand of CDROM do you recommend?

[Thomas Schmitt]

Hi,

 can anybody please give me some recommendations for long term archiving of
 data.
 Which brands are known to be usable for this?

Brands are not a reliable guideline, i fear. You can read different
manufacturer ids from media of the same brand, just bought a year
apart (or just a shop apart).
Even Verbatim has gone promiscuous meanwhile.

If you successfully checkread the archived media after writing,
then you have good chances for a long life of the archive.
You should of course re-check during that lifetime.
I would store at least two copies at different places and hope
that the second copy is still ok when the first one fails its
yearly test (or vice versa).
The more copies, the more hope.

My oldest (outdated) CD-RW backup is from 2003 and still passes
the yearly random sample test. (One out of 60 CDs is checkread.)

It will be convenient and more fool-proof if you store checksums
on the same medium which they shall guard.

Actually the optical media all have own checksums and error correction
which are used internally by the drive. I had two cases, though, were
DVD+RW media returned false data without error indication.
So an own MD5 or SHA-1 helps to make clear that the data are still
as they should be.

One may discuss whether the lower density of CD or the more
sophisticated checksums of DVD and BD are to prefer.
I would make the proposed copies on media of different manufacturer
and/or media type (e.g. DVD-R versus DVD+R).


Said this, my youngest BD burner bears a logo M (swirl) DISC,
which means Millenial Disc. This is DVD+R or BD-R with mineral dye.
  http://en.wikipedia.org/wiki/M-DISC
The web shows positive and negative opinions.
One thing is certain: They are more expensive than other media
of the same capacity.

There are archive formats like RAR, which are prepared for the
loss of chunks of archive data.
  http://en.wikipedia.org/wiki/RAR
Optical media are supposed to fail partially first. So there is hope
that in the beginning of deterioration, enough redundant intermixed
archive parts stay readable.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/2656466705538872...@scdbackup.webframe.org

Re: Long term archiving - which brand of CDROM do you recommend?

[Thomas Schmitt]

Hi,

i forgot to mention quality checkers like QPxTool

  http://qpxtool.sourceforge.net/

or the MS-Windows programs which are shown as screenshots in
CD/DVD/BD discussion forums.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/5004667045879446...@scdbackup.webframe.org

Re: xorriso: how to find fixed-string filenames?

[Thomas Schmitt]

Hi,

  You already get a warning when loading a non-ISO-image.
 There is one small shortcoming though: if the input image is not an iso
 but is filled with only nulls (or is empty), then xorriso does not fail

Yes. Such files count as blank medium.
I did not think of this case when making the proposal to you.


 I had expected that such a complex piece as xorriso would be able to do
 that itself (testing that the input is blank).

It does recognize this state. But it already has an own
harmless interpretation for it: blank medium suitable
for writing.
On such a medium it starts by an empty ISO image model.
This is a normal media state. No reason for a warning.

You get a warning, though, if you submit a non-blank non-ISO.
That's because these media have to be blanked before an
ISO session can be written to them.

You may probably recognize the blank-ISO situation by a
reply 0 from:

  xorriso -indev not_existing_file -ls / -- \
 2/dev/null | wc -c


  In xorriso's -find, -exec is not a test and can only appear once.
  [...] It would be quite some effort to enable multiple -exec

 That is why I suggested a different name of -fexec that would be a test.

I missed this point.


 What I had in mind is the possibility to make arbitrary tests against
 the filename only (that would be passed on the command line of a system
 command) and possibly against other attributes like size, mode, time
 that would be passed as environement variables ISO_SIZE, ISO_MODE etc.
 
   $ xorriso -indev img.iso -find \
   -fexec sh -c 'test $1 = $2 || test $ISO_MODE = 755' s $name '{}'
\; \
   -exec lsdl

Reading man bash ...

I understand that $1 and $2 shall become the value of shell
variable $name (evaluated by the shell that starts xorriso) and
the path of the currently examined ISO file object (caused by '{}').
The parameter range of -fexec shall end at \;.
s is a dummy sacrifice to the -c interpreter of sh, so that $name
does not become $0.

I'm not happy with the semicolon. Probably a user-defined separator
word is preferrable. It would be the first parameter of -fexec and
its next occurence would mark the end of -fexec.
Like
  -fexec + sh -c ... +

Similarly i'm not happy with '{}', because it would be a reserved
word among the parameters of fexec.
The solution could be user-defined word given as second parameter.
Like
  -fexec + +path /bin/sh -c ... s $name +path ... +

The user could still make it behave quite shell-ish then:
  -fexec ';' '{}' /bin/sh -c ... s $name '{}' ... ';'

I'm also not happy with the potential to perform arbitrary actions
on the computer system. One can easily shoot one's foot.
But i accepted this for -concat pipe and external filters already.
So this is not a hard obstacle. I just insist in not using $PATH
for finding the external program.

I'll put this proposal on my ponder-and-todo list.


 I think that it is important to have the possibility to disable patterns
 (or regexps), as the alternative is often to have to escape them, which
 is not portable I believe,

Especially xorriso does not support escaped wildcards.
Either -iso_rr_pattern interpretation is enabled or disabled
for a whole command.

There are two reasons for this reluctance to follow the shell
habits:
- xorriso tries to avoid interpretation collisions with the special
  words and characters of a shell.
  (E.g. i do not use ';' as separator by default, because then
   one would have to protect it from interpretation by the shell.)
- I deem several traditional syntax and semantic gestures of
  Bourne Shell descendants cumbersome. Among them is escaping
  of special or unprintable characters, and the behavior of 
  commands like cp and cd with multiple file arguments.
  Further, the shell is too eager to execute external programs,
  which is something you would not necessarily expect from a
  program that produces ISO 9660 filesystems.
  
I am aware that by this i deny certain features to my users,
which a shell would be able to offer.
(Given the architecture of libisoburn API, it would be well
 possible to wrap xorriso's commands into a real shell-ish
 interpreter, or a programming language like Tcl.)


  This feature is now in the SVN of libisoburn.

 I haven't had a chance to test it yet.

That's quite convenient for both of us. :)
I just found a bug with the recognition of -or_use_pattern
and wonder how it could pass my tests two weeks ago.
  http://libburnia-project.org/changeset/5327


xorriso -indev image.iso -return_with WARNING 32 -report_about WARNING \
  -find / -use_pattern off \
  -wholename $name1 -or -wholename $name2 -exec lsdl

 This does not even fail when none of the files are found.

-find is not supposed to warn if no file is found.
This situation would be rather be recognizable by no output on
stdout.

From your initial mail of 16 Apr 2014 07:00:22 +0200, where you
report about your experiments:
   xorriso -indev image.iso -return_with WARNING 32 -report_about WARNING \
-find 

Re: xorriso: extracting files to stdout

[Thomas Schmitt]

Hi,

i have now uploaded

  http://www.gnu.org/software/xorriso/xorriso-1.3.7.tar.gz

with -find pseudo tests -use_pattern , -or_use_pattern,

  -use_pattern   on|off   :  This  pseudo  test  controls  the
  interpretation of wildcards with tests  -name,  -wholename,  and
  -disk_name.  Default  is  on. If interpretation is disabled by
  off, then the parameters of -name, -wholename, and  -disk_name
  have  to  match  literally  rather than as search pattern.  This
  test itself does always match.

  -or_use_pattern   on|off   :Like-use_pattern,but
  automatically  appending  the  test  by -or rather than by -and.
  Further the test itself does never match. So a  subsequent  test
  -or will cause its other operand to be performed.

and with new command -concat (which needs to be enabled by -osirrox on):

  -concat mode [target | lim prog [args [...]] lim] iso_rr_path [***]
  Copy the data content of one or more data files of the ISO image
  into  a  disk  file  object,  into a file descriptor, or start a
  program and copy the data into its standard input.   The  latter
  is subject to the security restrictions for external filters.

  Modes overwrite and append write into the target  which is given
  by the second parameter. This may be the path  to  a  disk  file
  object,  or  -  which  means standard output, or a text of the
  form /dev/fd/number, where number is  an  open  file  descriptor
  (e.g.  standard error is /dev/fd/2).  An existing target file is
  not removed before writing begins. If it is  not  able  to  take
  content data, then this command fails.  Mode overwrite truncates
  regular data files to 0 size before writing into them.  Example:
   -concat append /home/me/accumulated_text /my/iso/text --

  Mode  pipe  expects  as  second parameter a delimiter word which
  shall mark the end of  the  program  argument  list.  The  third
  argument  is  the  disk_path  to the program. It must contain at
  least one '/'. $PATH is not applied.  Further parameters  up  to
  the  announced  delimiter  word  are  used as arguments with the
  program start. Example:
   -iso_rr_pattern on \
   -concat pipe + /usr/bin/wc + /my/iso/files* --

  The further parameters in all modes are the iso_rr_paths of data
  files.  Their content gets concatenated in the copy.

The mentioned security restrictions are this command:

  -close_filter_list
  Irrevocably ban commands -concat pipe,  -external_filter,  and
  -unregister_filter,  but  not  -set_filter.  Use this to prevent
  external filtering in general or when all intended  filters  are
  registered   and   -concat  mode  pipe  shall  be  disallowed.
  External filters may also be banned totally at compile  time  of
  xorriso.   By  default  they  are  banned  if xorriso runs under
  setuid permission.

and these ./configure options (documented in README):

  xorriso allows to use external processes as file content filters. This is
  a potential security risk which may be avoided by ./configure option
  --disable-external-filters

  By default the filter feature is disabled if effective user id and real
  user id differ. This ban can be lifted by
  --enable-external-filters-setuid

Test reports are welcome.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/5313670240801927...@scdbackup.webframe.org

Re: BD-R burn errors

[Thomas Schmitt]

Hi,

 Changed it to =spare:none
 and then burned two BD-R at 21 GByte.  Both finished normally and verified.
 The log reports did not include the background format message either.

So this was the unformatted case of BD-R.
No checkreading during write, no replacement of bad blocks,
no pseudo-overwrite at the end of the burn.
So the close track command was welcome and executed.


 Performance was also significantly increased.  It started at 3.4x and then
 normalized around 2.8x.  That is the best I have seen on anything related to
 BD media. [...]
 I would be interested in knowing what can be achieved in performance.  The
 drive is rated at 16x and the media is 6x.

It is supposed to perform with the nominal speed of drive and medium.
So it should be 6 x 4495 MB/s = nearly 27 MB/s.
But the drive may well have decided to restrict itself to 4x on that
medium.

If you got many files in the composition, then possibly the hard disk
filesystem is not fast enough with hopping from file to file.

You could test by first creating an ISO image on a hard disk which
should have lots of free space so that it does not have to heavily
fragment the image file.
Then burn that image to BD-R. Disk performance is supposed to be
much better then ... if it was the bottle neck at all.


 Nice improvement.

Still there is the riddle why dvd+rw-format did not work for you.
(If you try again, please record the message output. I'm curious.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/1185867031507183...@scdbackup.webframe.org

Re: BD-R burn errors

[Thomas Schmitt]

Hi,

  The workaround has to be applied to the unused BD-R _before_
  K3b resp. growisofs get to see it.
 These were unused (brand new) media I attempted to format.

Strange. In order to get to the bug, growisofs must have succeeded
with formatting. Why did dvd+rw-format not work ?

I would be curious to see the message output of such an attempt.


Whatever: The other possible workaround (except building a fixed
growisofs from source), would be to talk K3b into using growisofs
option
  -use-the-force-luke=spare:none
In that case, the BD-R would stay unformatted and the final command
would be appropriate. I.e. it should succeed and growisofs should
end happily.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/26249669708946528...@scdbackup.webframe.org

Re: BD-R burn errors

[Thomas Schmitt]

Hi,

  Or I may have had =ssa:none.  From what I could tell in the source
 file dvd+rw-format.cpp it should be equivalent.

ssa is not among the Luke Forces of growisofs.c.
There it would have to be 
  -use-the-force-luke=spare:none
or
  -use-the-force-luke=spare=none

This is equivalent to dvd+rw-format options -ssa=none or -spare=none.
But the bug does not happen due to a dvd+rw-format run.
It happens when growisofs formats the BD-R before writing.


As you are already inspecting the source code: How about giving
the bug fix a chance:

--- growisofs_mmc_orig.cpp   2013-06-14 19:53:51.0 +0200
+++ growisofs_mmc.cpp   2013-06-14 19:55:25.0 +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();

Several people confirmed that it silenced the error message at
the end of the burn run.


 So I have been
 considering just using BD-RE media since it appears to be working well.

They are indeed a very fine kind of medium. Just a bit slow for
their size. On the other hand, the drives keep a civilized noise
level when writing BD-RE. 6x BD-R sounds more like a sawmill.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/2631067037790875...@scdbackup.webframe.org

Re: xorriso: extracting files to stdout

[Thomas Schmitt]

Hi,

 I want to pass a fixed list of filenames to list.  The best way seems to
 be to use -wholename and hope that filenames do not contain special
 pattern characters:
 
   xorriso -indev image.iso -return_with WARNING 32 -report_about WARNING \
 -find / -wholename $name1 -o -wholename $name2 -exec lsdl
 
 Is there a way to avoid the interpretation of these patterns by xorriso
 or another way to list file with a fixed-string filename?

Currently not. (Again :))

Do i get it right that you want to get a non-zero exit value from
the program run if none of the files in the list exists in the ISO ?

Maybe you would be better off with a simple -ls command while
wildcard expansion is disabled by -iso_rr_pattern off:

  $ xorriso -indev /some/non-ISO \
-return_with WARNING 32 -report_about WARNING \
-iso_rr_pattern off \
-ls /such*.c --
  GNU xorriso 1.3.7 : RockRidge filesystem manipulator, libburnia project.

  xorriso : WARNING : Not found in ISO image: '/such*.c'

although a file /such.c does exist in the ISO image. It would be
listed without warning if -iso_rr_pattern was set to on or to ls.


 The -return_with WARNING is there to fail if no file could be found
 (which is the case if image.iso is not a valid iso).

You already get a warning when loading a non-ISO-image.

  $ xorriso -indev /some/non-ISO \
-return_with WARNING 32 -report_about WARNING
  GNU xorriso 1.3.7 : RockRidge filesystem manipulator, libburnia project.

  libisoburn: WARNING : No ISO 9660 image at LBA 0. Creating blank image.
  $ echo $?
  32

The commands -report_about and -return_with are already in effect
when the interpretation of -indev happens. That's because more than
one such setting might be desired. By this rule they do not have to
fight for being first command in the list.
(Normally commands get into effect only after all previous commands
 in the argument list have been executed.)

If you really want to tolerate a WARNING with -indev and later take
WARNING as cause for a non-zero exit value, then you first have to
set the event thresholds to a higher severity for the duration
of the -indev command:

  xorriso -return_with FAILURE 32 -report_about WARNING \
  -indev /some/non-ISO \
  -return_with WARNING 32 \
  -find ...


If you just want to know whether a data file is an ISO image
or not, you could also use the shell command file

  $ file test.iso
  test.iso: ISO 9660 CD-ROM filesystem data '...Volume.Id...'

  $ file not_an_iso
  not_an_iso: ASCII text

---

 Maybe adding a -find_pattern option or making -iso_rr_pattern enable/disable
 the use of patterns by -find would be a good idea?

For compatibility reasons, it would inot be appropriate to extend
the effect of -iso_rr_pattern and -disk_pattern to -find tests.

But one could introduce pseudo tests -iso_rr_pattern and -disk_pattern
which always return true and control pattern interpretation. Like:

  -find / -iso_rr_pattern off ...more.tests.and.one.action...


 The system find has a similar issue, but there is a way to find fixed
 filenames by using the option -exec

In xorriso's -find, -exec is not a test and can only appear once.


 Would you consider adding a -fexec to your -find to use a system command
 to test a filename (and maybe more than the filename)?

That would be applicable to disk files, but not to files in the
ISO image.
It would be quite some effort to enable multiple -exec with arbitrary
xorriso commands and to attribute exit values to those commands.
This feature of POSIX find depends on the concept of a shell resp.
of POSIX program execution. xorriso would have to mimic this.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/5067669717947271...@scdbackup.webframe.org

Re: xorriso: extracting files to stdout

[Thomas Schmitt]

Hi,

first the correction of a deceiving typo in my previous mail:
 So you see any use case where a regular data file should be
 overwritten rather than being replaced ?

I meant Do rather than So:
Do you see any use case where a regular data file should be
overwritten rather than being replaced ?


Musings about -extract and unlinking its target files:

In any case the default of xorriso will stay unlink any file.
Now i ponder about the non-default options.

The permission to follow symbolic links would have to be separated
from the permission to keep a target file of suitable type linked.
(If my above corrected question yields yes then there would be the
 need for a third permission: do not unlink regular files.)

Further the extraction source might be no regular data file. In this
case it will not be possible to write its content into existing
file objects on hard disk.
If in do not unlink mode, shall this lead to refusal or shall
the target object be unlinked and replaced by a copy of the source ?


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/29150669737412163...@scdbackup.webframe.org

Re: xorriso: how to find fixed-string filenames?

[Thomas Schmitt]

Hi,

i now understand why command -ls is not what you need:
It warns if any of the given files is missing.
You want a warning if all given files are missing.

So i implemented two new -find tests:

  -use_pattern   on|off   :  This  pseudo  test  controls  the
  interpretation of wildcards with tests -name,  -whole_name,  and
  -disk_name.  Default  is  on. If interpretation is disabled by
  off, then the parameters of -name, -wholename, and  -disk_name
  have  to  match  literally  rather than as search pattern.  This
  test itself does always match.

  -or_use_pattern   on|off   :Like-use_pattern,but
  automatically  appending  the  test  by -or rather than by -and.
  Further the test itself does never match. So a  subsequent  test
  -or will cause its other operand to be performed.

I do not see a need to distinguish between iso_rr files and disk files.
If the user wants a particular setting for the next test, then this
can be done immediately before it by inserting one of above pseudo
tests.
The logical operator before the next test decides which of both
pseudos is more appropriate:
  -test1 [-and] -use_pattern off [-and] -test2
or
  -test1 -or_use_pattern off -or -test2

Your example could look like

  xorriso -indev image.iso -return_with WARNING 32 -report_about WARNING \
-find / -use_pattern off \
-wholename $name1 -or -wholename $name2 -exec lsdl

One could also use patterns and non-patterns mixed

-find / -use_pattern off -wholename $name1 \
-or_use_pattern on -or -wholename $name2'*' \
-or_use_pattern off -or -wholename $name3 

-

This feature is now in the SVN of libisoburn.

I plan to upload a new development tarball of GNU xorriso, when we
have discussed your other wish (about extraction) and i eventually
have implemented some solution.

Ping me if you want to try the new -find tests first.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/12689669757490996...@scdbackup.webframe.org

Re: BD Drive performance

[Thomas Schmitt]

Hi,

 Seeking recommendations for a new acquisition of BD-RE type drive that will
 function at rated performance.

They all should do, if no Defect Managment is involved and
if the computer and bus can deliver the necessary data rate.

A few months ago i bought an LG BH16NS40. It does 2.0x on
2x BD-RE media with xorriso and Stream Recording.
(Regrettably it does not reach the 2.3x speed of the old
 GGW-H20L.)

A problem with any advise is that drive models change frequently
and that the sucessor model might be a completely different
drive with completely different firmware. It's a very promiscuous
market.


 Normally .5x burns are typical and 1x is possible with special
 options.

I assume you mean Stream Recording or formatting without Spare Area.
Further assumed you use normal 2x media, i wonder what might
slow down your data transfer.

What driver buffer fills are reported with your burn runs ?


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/1545664122369340...@scdbackup.webframe.org

Announcing cdrskin-1.3.6.pl01

[Thomas Schmitt]

Hi,

libburnia project made an unplanned bug fix release 1.3.6.pl01 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread


Changes:

* Bug fix: CD TAO with multiple tracks or with add-on sessions could
   cause a buffer overrun by one 0-byte.
   This is an old bug present since version 0.3.2, 7 years ago.

* Bug fix: Compilation warning for unsupported systems mutated into an error.
   This is a regression introduced by release 1.3.6.


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.3.6.pl01.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.3.6.pl01.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.3.6.pl01.tar.gz.sig cdrskin-1.3.6.pl01.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.3.6pl01. SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.3.6.pl01
(needs autotools = 1.7 to apply command ./bootstrap)

and of the libburn-1.3.6.pl01 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.3.6.pl01.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/6293663600782790...@scdbackup.webframe.org

GNU xorriso 1.3.6.pl01 released

[Thomas Schmitt]

Hi,

libburnia project made an unplanned bug fix release 1.3.6.pl01 of
GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.3.6.pl01.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: CD TAO with add-on sessions could cause a buffer overrun
   by one 0-byte.
   This is an old bug present since version 0.3.2, 7 years ago.

* Bug fix: Compilation warning for unsupported systems mutated into an error.
   GNU xorriso is not able to burn optical media on such systems,
   but is needed as prerequisite of GRUB2 tool grub-mkrescue.
   This is a regression introduced by release 1.3.6.

* Bug fix: Command -status produced FAILURE event if no drive was acquired.
   This is a regression introduced by release 1.3.6.


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread
- NetBSD   : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at
your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.3.6.pl01.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.3.6.pl01.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/1340663600413292...@scdbackup.webframe.org

Announcing cdrskin-1.3.6

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.3.6 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread
or NetBSD  : libc, libpthread


Changes:

* System adapter for NetBSD


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.3.6.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.3.6.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.3.6.tar.gz.sig cdrskin-1.3.6.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.3.6 SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.3.6
(needs autotools = 1.7 to apply command ./bootstrap)

and of the libburn-1.3.6 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.3.6.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/8399666057923991...@scdbackup.webframe.org

GNU xorriso 1.3.6 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.3.6
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.3.6.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: Division by zero if HFS+ was combined with TOC emulation
   for overwritable media.

* Bug fix: -list_speeds did not work any more with old CD drives.
   Regression introduced by release 1.3.4

* Bug fix: -check_media marked untested sectors in sector map as valid

* Bug fix: Paths with symbolic links preceding .. were not interpreted
   properly

* New -compliance rule joliet_utf16, new -as mkisofs option -joliet-utf16

* New -find test -bad_outname, new -find action print_outname

* New API call isoburn_conv_name_chars()

* System adapter for NetBSD


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread
- NetBSD   : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at
your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.3.6.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.3.6.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/10609666055676452...@scdbackup.webframe.org

Re: identical iso to and from dvd+rw

[Thomas Schmitt]

Hi,

 please, how to write a given iso file to a medium (dvd+rw in my case) and
 then extract the same iso (same in the sense of length and checksum) from
 the medium? Is this even possible?

Write it to the medium by normal means (dd, growisofs, cdrecord,
cdrskin, ...). The decisive trick is to only read as many bytes
as you wrote.
So memorize the original size of the iso file.

The size of the ISO filesystem inside the file and on medium
can be determined by tools like isosize or xorriso. But this might
be smaller than the size of the image file.
(You decide which of both sizes really does matter to you.)

Whatever, if you have the size then just read that amount from
the medium.

Assumed the size is integer divisible by 2048, use block size 2048
and the division result. E.g. if your file has a size of
4,581,523,456 bytes, then it has 2,237,072 blocks, So use

  dd if=/dev/sr0 bs=2048 count=2237072 of=my_extracted.iso


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/2691564222058598...@scdbackup.webframe.org

GNU xorriso 1.3.4 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.3.4
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.3.4.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: Command -blank as_needed formatted blank BD-R.

* Bug fix: -as mkisofs option -log-file put the log file into the image

* Bug fix: -cut_out did not add x-permission to r-permission of directory

* Bug fix: Command -zisofs did not accept all options emitted by
   -status -zisofs

* Bug fix: -blank force:... failed on appendable or closed media

* Bug fix: libburn: Drive LG BH16NS40 stalled on inspection of unformatted
DVD+RW

* libisofs: Default sort weight of El Torito boot images is now 2

* libisofs: Encoding HFS+ names in UTF-16 rather than UCS-2

* New command -read_speed

* New -close mode as_needed, new -as cdrecord option --multi_if_possible

* New -alter_date types: a-c , m-c , b-c , c


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at
your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.3.4.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.3.4.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/8302638527684439...@scdbackup.webframe.org

Announcing cdrskin-1.3.4

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.3.4 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread


Changes:

* Bug fix: Drive error reports were ignored during blanking and formatting

* Bug fix: Drive LG BH16NS40 stalled on inspection of unformatted DVD+RW


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.3.4.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.3.4.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.3.4.tar.gz.sig cdrskin-1.3.4.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.3.4 SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.3.4
(needs autotools = 1.7 to apply command ./bootstrap)

and of the libburn-1.3.4 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.3.4.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/1069663852943822...@scdbackup.webframe.org

Announcing bug fix release cdrskin-1.3.2.pl01

[Thomas Schmitt]

Hi,

due to an outdated softlink at packaging time, the tarball
  cdrskin-1.3.2.tar.gz
contains the outdated and buggy source of cdrskin-1.3.0.

This does not affect the cdrskin code in tarball libburn-1.3.2.tar.gz.
So most distro packagers will not have to take any action.
(Please check your scripts resp. configuration files whether
 they use cdrskin*tar.gz or libburn*.tar.gz.)

A new tarball cdrskin-1.3.2.pl01.tar.gz has now been uploaded.
It unpacks to directory ./cdrskin-1.3.2.


System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread


The following changes failed to become part of the old tarball:

* Bug fix: cdrskin -msinfo on DVD and BD reported
   old session start = next writable address.
   Regression introduced by version 1.2.8 (rev 4956).
   Already fixed by patch release 1.3.0.pl01.

* New cdrskin option textfile_to_v07t=

* New cdrskin options cdtext_to_textfile= and cdtext_to_v07t=

* New cdrskin options extract_audio_to= , extract_tracks= , extract_basename= ,
  --extract_dap

* New cdrskin option --pacifier_with_newline


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.3.2.pl01.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.3.2.pl01.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.3.2.pl01.tar.gz.sig cdrskin-1.3.2.pl01.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.3.2 SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.3.2
(needs autotools = 1.7 to apply command ./bootstrap)

and of the libburn-1.3.2 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.3.2.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/10998647526586458...@scdbackup.webframe.org

Announcing cdrskin-1.3.2

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.3.2 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or newer: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread


Changes:

* Bug fix: cdrskin -msinfo on DVD and BD reported
   old session start = next writable address.
   Regression introduced by version 1.2.8 (rev 4956).
   Already fixed by patch release 1.3.0.pl01.

* Bug fix: The signal handler aborted on SIGCONT, SIGTSTP, SIGTTIN, SIGTTOU

* New cdrskin option textfile_to_v07t=

* New cdrskin options cdtext_to_textfile= and cdtext_to_v07t=

* New cdrskin options extract_audio_to= , extract_tracks= , extract_basename= ,
  --extract_dap

* New cdrskin option --pacifier_with_newline

* Improved granularity of SCSI log time measurement, now with timestamp


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.3.2.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.3.2.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.3.2.tar.gz.sig cdrskin-1.3.2.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.3.2 SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.3.2
(needs autotools = 1.7 to apply command ./bootstrap)

and of the libburn-1.3.2 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.3.2.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/8425648519776919...@scdbackup.webframe.org

GNU xorriso 1.3.2 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.3.2
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.3.2.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: -find -exec sort_weight did not mark the image as having
   pending changes

* Bug fix: -backslash_codes with_program_arguments was interpreted too late

* Bug fix: Missing or empty parameter with -dus was interpreted as * rather
   than .

* Bug fix: readline history was spammed by -msg_op parsing and pipe loops

* Bug fix: xorriso aborted on SIGCONT, SIGTSTP, SIGTTIN, SIGTTOU

* Improved granularity of SCSI log time measurement, now with timestamp

* New -pacifier behavior code interval=

* New -as mkisofs options --sort-weight-list and --sort-weight-patterns

* New -format mode without_spare (for BD-RE)

* New command -named_pipe_loop

* New command -sh_style_result

* New -msg_op opcodes parse_silently and parse_bulk_silently

* New command -application_use and new -as mkisofs option --application_use


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or newer, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at
your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.3.2.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.3.2.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/11620648519927512...@scdbackup.webframe.org

Re: USB Port speeds

[Thomas Schmitt]

Hi,


James Finnall wrote:
 Responses below for the suggested commands.
 stream_recording seems to have nailed the issue down.

Let's see what the test results can teach us. :))

(Re-ordered sequence:)

 media reported 0 blocks for spare area and it also reported blank.
 It was new media I used for above after formating with dvd+rw-format with
 -spare=none option.

So it is not really capable of Defect Management. It cannot replace
bad blocks by blocks from the 0-sized Spare Area.


  dd if=/dev/zero bs=1M count=1000 |  xorriso -as cdrecord -v dev=/dev/sr0 -
 This reported .9x to 1.2x

The drive still seems to checkread. This is not totally insane
because in case of bad read quality of a chunk it could still
overwrite it once more. Such a double write might well make a poor
medium readable.

But we want full speed trusting on good media quality and betting on
good luck. (If we lose, then the whole medium has to be re-written.)


  dd if=/dev/zero bs=1M count=1000 | xorriso -as cdrecord -v dev=/dev/sr0 
  stream_recording=on -
 This reported 2.0x and 100% buffer fill through the operation. (@ 8.6 MB/s)

The drive obeys the urge of my WRITE(12) commands with Streaming bit
set to 1.

MMC specs do not directly promise that this disables checkreading,
but the goal of this feature is to ensure timely writing at the
expense of the risk of bad blocks staying unreplaced.


 I read the man page regarding stream_recording but not sure that I fully
 understand what the problem is exactly.

MMC mentions a feature called Stream Recording and prescribes how
it shall be controlled by the computer system (Host).
MMC-5 4.8.4 Real-Time Stream Recording:
The Host should use WRITE (12) command with Streaming bit set to
 one to perform the Stream recording operation. The Drive shall not
 perform the Linear Replacement operation for defective block.
 The Drives performance shall be at least 1x speed even if this
 prevents the Drive from retry or verify operation.

It turns out, that 1x speed is interpreted as nominal speed
by all drives about which i have reports.
Thus no speed reducing checkreading happens during the write run.


 Since K3B wants to use growisofs does it have some ability to overcome the
 problem?

Although Andy Polyakov decided against Stream Recording in growisofs,
there is code prepared in dvd+rw-tools-7.1/growisofs_mmc.cpp :

=
while (1)
{   cmd[0] = wrvfy?0x2E:0x2A;   // WRITE [AND VERIFY] (10)
cmd[2] = (lba24)0xff;// Logical Block Addrss
cmd[3] = (lba16)0xff;
cmd[4] = (lba8)0xff;
cmd[5] = lba0xff;
cmd[7] = (nbl8)0xff;
cmd[8] = nbl0xff;
cmd[9] = 0;
#if 0
cmd[0] = 0xAA;  // WRITE(12)
cmd[2] = (lba24)0xff;// Logical Block Addrss
cmd[3] = (lba16)0xff;
cmd[4] = (lba8)0xff;
cmd[5] = lba0xff;
cmd[8] = (nbl8)0xff;
cmd[9] = nbl0xff;
cmd[10] = 0x80; // Streaming
cmd[11] = 0;
#endif
=

Remove the use of WRITE(10) and the disabling #if around WRITE(12).
This should hardcode the behavior of xorriso's stream_recording.

=
while (1)
{
cmd[0] = 0xAA;  // WRITE(12)
cmd[2] = (lba24)0xff;// Logical Block Addrss
cmd[3] = (lba16)0xff;
cmd[4] = (lba8)0xff;
cmd[5] = lba0xff;
cmd[8] = (nbl8)0xff;
cmd[9] = nbl0xff;
cmd[10] = 0x80; // Streaming
cmd[11] = 0;
=


 One of my intentions for the BD-RE is script control backups under cron.  In
 the CLI scripts I can certainly use xorriso.

Be invited. Either for wrapping the tarfiles into ISO 9660 systems
(see man xorriso) or by just burning one onto each BD medium
(see man xorrecord).
I promise help to achieve the goals of your script programming.


 However, since the backups are very large tar files then error checking
 becomes more important since tar files are essentially sequential in nature
 and error stops all read operations  Your thoughts on on reliability?

If your drive and media cannot produce flawless media in the vast
majority of tries, then Defect Management might be of help.
I.e. format your BD-RE to a moderate amount of Spare Area and do not
use Stream Recording.
The price is half nominal speed.

If your drive and media normally show no failures, then it is a
good bet to use Stream Recording.
One should check-read the result, of course. But that can be done
later and with a second drive. (Ensuring readability on the reserve
backup drive is an important part of backuping, anyway.)

There is QPXtool which can possibly judge the quality of drive
and media. The possibility depends on the particular 

Re: USB Port speeds

[Thomas Schmitt]

Hi,

 The format
 option of -spare=none did help to at least double the performance as you
 thought.  I was able add the parameter to the command in K3B settings as
 well.

At least with previously used BD-RE media it will not help to
have this option with growisofs. It is intended to prevent
auto-formatting of blank BD-R media. There it is beneficial indeed.

BD-RE must be stripped of their Spare Area by dvd+rw-format.


 the search
 button in K3B would not offer any other choices than what was provided.

They ignore my programs since years. (Shrug)


 So the performance doubled as you expected but still nowhere near what the
 DVD performance was able to get. (4500 KB/s vs. 14000 KB/s)

2x BD speed should be about 9000 KB/s.
4500 still looks like checkreading.

What speed reports do you get from

  dd if=/dev/zero bs=1M count=1000 | \
   xorriso -as cdrecord -v dev=/dev/sr0 -

and from

  dd if=/dev/zero bs=1M count=1000 | \
   xorriso -as cdrecord -v dev=/dev/sr0 stream_recording=on -


 Would I still have the same problem if directly attached to a SATA port?  It
 sounds like I would.

If you can test it then we would know whether the USB driver
is involved.

With my own USB attached drives i have problems when speed
gets to 12x DVD which is about 16 MB/s. On a slightly more
modern machine, the same USB boxes run up to 20x DVD speed.

On my olde machine, the block device driver can read with 
about 20 MB/s whereas my userspace MMC driver gets only
16 MB/s. There seem to be timing and priority problems.
A SATA attached DVD burner at the old machine does 20x
with my userspace driver.

But that all happens far above 10 MB/s.


 At this point I am not sure as to what is the best direction, look for
 another drive or different media.  Any thoughts from your past performance /
 experiences?
 Would drive firmware update help this issue (if available)?

I don't think it is a matter of the BD-RE media if they are
really formatted to 0 Spare area. Bad media would cause write
errors or read errors but should not be slow if Defect Management
is sucessfully disabled.

To verify that state, run
  xorriso -outdev /dev/sr0 -list_formats
It should report before a list of format proposals:
  Format status: formatted, with 23866.0 MiB
  BD Spare Area: 0 blocks consumed, 0 blocks available


 I also have 6x BD-R media but since they are not erasable I prefer not to
 just waste them on silly tests to determine what performance I can get.

There is the CLOSE SESSION bug of growisofs with BD-R.
You may want to try my fix proposal for growisofs_mmc.cpp as of
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713016
before or after you got hit by that bug.

When it seems necessary to waste BD-R, then you may leave them
appendable (by xorriso -as cdrecord option -multi) and make more
than one experiment with the same medium.
About 22 sessions of 1 GB should fit. Probably one could reduce
session size to a few hundred MB and still get meaningful
measurements.

But for now, 2x BD-RE is a good goal.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/3043628040401523...@scdbackup.webframe.org

Bug fix release cdrskin-1.3.0.pl01

[Thomas Schmitt]

Hi,

a nasty regression has been found in cdrskin-1.2.8 and cdrskin-1.3.0:
Option -msinfo reported identical numbers for the start of the most
recent session and the predicted start of the next session.

Please upgrade these versions to the new patch release cdrskin-1.3.0.pl01,
which unpacks to directory ./cdrskin-1.3.0.


System requirements:
   Linux with kernel 2.4 or 2.6: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread


Changes:

* Bug fix: cdrskin -msinfo on DVD and BD reported
   old session start = next writable address.
   Regression introduced by version 1.2.8 (rev 4956).


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.3.0.pl01.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.3.0.pl01.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.3.0.pl01.tar.gz.sig cdrskin-1.3.0.pl01.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.3.0.pl01 SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.3.0.pl01
(needs autotools = 1.7 to apply command ./bootstrap)

and of the libburn-1.3.0.pl01 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.3.0.pl01.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/13277621665526546...@scdbackup.webframe.org

GNU xorriso 1.3.0 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.3.0
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.3.0.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: Disk paths with components '.' or '..' could be mistaken for
   directories.

* Bug fix: -as mkisofs -print-size failed with -isohybrid-mbr and a single
   boot image. Regression introduced by libisoburn-1.2.8.

* Bug fix: -as mkisofs -path-list did not switch to --no-emul-toc by default.

* Bug fix: Unspecified Expiration Time and Effective Time of ISO volume was
   represented by 0-bytes rather than ASCII '0' digits.

* Bug fix: Reserved and unused fields of APM entries were not zeroed.

* Bug fix: GPT header CRC was computed from all 512 bytes rather than from 92.

* Bug fix: The protective MBR partition for GPT started at block 0 instead of 1.

* New -boot_image bootspecs grub2_mbr= and grub2_boot_info=

* New -boot_image bootspec grub2_sparc_core=

* New -as mkisofs options --grub2-mbr , --grub2-boot-info , --grub2-sparc-core

* New -hardlinks mode lsl_count / no_lsl_count


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or 2.6, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at
your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.3.0.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.3.0.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/15175624040701578...@scdbackup.webframe.org

Re: Issues brining BD disks from the command line - write failures

[Thomas Schmitt]

Hi,

 Or you could be dealing with a stupid Linux kernel that hasn't got fixed
 for the last 15 years. If the recording ends at the end of the
 filesystem (common, for obvious reasons) and the size of the filesystem
 is not a multiple of some internal Linux buffer size, the last buffer
 Linux tries to read is incomplete and gets treated with an I/O error,
 although the only error is that of the programmer trying to read past
 the end of the legimitate recording.

This happens only with CDs which were written in write type TAO.
The stupidity is equally distributed over Linux and MMC specs.

The MMC specs prescribe that a TAO track ends by two non-data
sectors. These sectors are counted as part of the track size.

Linux blindly believes the announced track size from the CD
table-of-content and tries to read the two non-data sectors, too.
So far so good. One cannot distinguish TAO form SAO CDs easily
and thus has to try. The Linux stupidity is to drop the whole cache
tile (i believe it is 128 KB) that would contain those two blocks.
This means to also drop up to 124 KB of perfectly readable data.

Nevertheless, that is a _read_ problem. Dale has a problem with
write errors. The read-ahead bug has never been observed with
DVD or BD, anyway.


 The other good thing to do with Linux is to append 2MByte of zeros at
 the end of the filesystem

To my experience, 128 KB is enough. Tradition is 300 KB, out of
a wrong perception of Linux bug and MMC specs.
Actually it depends on the size of reading ahead. So it might vary.


  I do not deem mkisofs to be the best ISO 9660 program. :))

 What are the options, though? (Not counting jokes like woedumb.)

xorriso.
If you want ISO 9660 then i dare to say it is better than mkisofs.


 And what are the options for UDF (which is becoming increasingly
 necessary)?

mkudffs and cp.

But for what, particularly ?
It is a misperception that the specs for DVD and BD would demand
UDF. It is the specs for commercial videos which demand UDF.
And the specs for BD demand a UDF variant which mkisofs does not
produce either.

I have looked into the specs (ECMA-167 and UDF-2.60, not nice to read)
and found nothing that would convince me of technical benefits.

If some user would approach me with the wish for UDF for video DVD
or video BD, then i would start developing ISO 9660 / UDF hybrids.
But that would need effort by the user, too. One would need hardware
that insists in specs-compliant DVDs. One would need the full specs
for video CD resp. BD. One would need time for testing.

No such user showed up yet.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/16264623796868281...@scdbackup.webframe.org

Re: Issues brining BD disks from the command line - write failures

[Thomas Schmitt]

Hi,

 Ehh, I'm very sure I've seen it with DVDs too, and the read-ahead size
 there was larger.

In that case we should try to reproduce the problem.

At least the Linux kernel would need another reason why to misperceive
the size of the medium on the first hand.
In case of CD it is obviously the MMC compliant inclusion of two
non-data blocks at the end of TAO tracks.

The block device driver does know (at least roughly) the size of a CD.

I believe to see the size determination in my olde
  /usr/src/linux/drivers/scsi/sr.c
in function
  static void get_sectorsize(struct scsi_cd *cd)
by
cmd[0] = READ_CAPACITY;
...
the_result = scsi_execute_req(cd-device, cmd, DMA_FROM_DEVICE,
  buffer, 8, NULL, SR_TIMEOUT,
  MAX_RETRIES);
...
cd-capacity = 1 + ((buffer[0]  24) |
(buffer[1]  16) |
(buffer[2]  8) |
buffer[3]);

This code matches the MMC description of the result of SCSI command
25h READ CAPACITY, which is supposed to tell the capacity [...] with
respect to reading operations.
In the context of MMC, reading is not only reading of data, but also reading
of non-data sectors. Thus, READ CAPACITY counts the two non-data sectors
of TAO as readable. (Just not by command 2Bh READ(10), but by BEh READ CD.)

As said, the fault of Linux is not to handle the last two blocks
of CD tracks specially, resp. not to retry by reading single blocks
after reading the last cache tile has failed.
It has to be aware that those two blocks may or may not be part of
the track's payload data. Some try-and-error is inavoidable here.
But the error should not be forwarded to the user and it should not
eat up more than the two questionable blocks.


  Nevertheless, that is a _read_ problem. Dale has a problem with
  write errors.

 Sure, but you asked him to test afterwards by reading back.

I see. Well, if there is a read-ahead bug with DVD then the
checkreading by dd could indeed produce false i/o errors at the
very end of the track.

A safer proposal would then be

  xorriso -outdev /dev/sr0 -check_media use=outdev --

If the medium is DVD+RW or BD-RE then there will be trailing stuff
anyway. One will have again to compute the size of the valid payload
like with my dd proposal, and then use -check_media option max_lba= :

  xorriso -outdev /dev/sr0 -check_media max_lba=1700758 use=outdev --

(-outdev has to be used if the medium content is not an ISO 9660
 filesystem. No writing will happen, because no xorriso command for
 creating or changing an ISO image is used here. Moreover, xorriso
 will not append data to a non-blank medium which it did not aquire
 as input drive. So this is safe.)




  mkudffs and cp.
  But for what, particularly ?

 Random-file-access backups.

That's the reason why i began to develop xorriso.
It can record ACLs and xattr, can register MD5 checksums of medium
and of each single data file, does incremental backups based on
either MD5 or on inode properties, and can checkread its own backups
without the need for seeing the original files.

Example from man xorriso:
  This  changes  the  directory trees /projects and /personal_mail in the
  ISO image so that they become exact copies of their disk  counterparts.
  ISO  file objects get created, deleted or get their attributes adjusted
  accordingly.
  ACL, xattr, hard links and MD5 checksums will be recorded.  Accelerated
  comparison is enabled at the expense of potentially larger backup size.
  Only media with the expected volume ID or  blank  media  are  accepted.
  Files with names matching *.o or *.swp get excluded explicitly.
  When  done  with  writing  the new session gets checked by its recorded
  MD5.

  $ xorriso \
-abort_on FATAL \
-for_backup -disk_dev_ino on \
-assert_volid PROJECTS_MAIL_* FATAL \
-dev /dev/sr0 \
-volid PROJECTS_MAIL_$(date +%Y_%m_%d_%H%M%S) \
-not_leaf *.o -not_leaf *.swp \
-update_r /home/thomas/projects /projects \
-update_r /home/thomas/personal_mail /personal_mail \
-commit -toc -check_md5 FAILURE -- -eject all

  To be used several times on the same medium, whenever an update of  the
  two  disk trees to the medium is desired. Begin with a blank medium and
  update it until the run fails gracefully due to lack of remaining space
  on the old one.
  [...] To apply zisofs compression to those data files which get
  newly  copied  from  the  local  filesystem,  insert   these   commands
  immediately before -commit :
-hardlinks perform_update \
-find / -type f -pending_data -exec set_filter --zisofs -- \

zisofs needs zlib and its development headers at compile time of xorriso.
Linux kernels 

Re: Issues brining BD disks from the command line - write failures

[Thomas Schmitt]

Hi,

 Ehh, I'm very sure I've seen it with DVDs too, and the read-ahead size
 there was larger.

In that case we should try to reproduce the problem.

At least the Linux kernel would need another reason why to misperceive
the size of the medium on the first hand.
In case of CD it is obviously the MMC compliant inclusion of two
non-data blocks at the end of TAO tracks.

The block device driver does know (at least roughly) the size of a CD.

I believe to see the size determination in my olde
  /usr/src/linux/drivers/scsi/sr.c
in function
  static void get_sectorsize(struct scsi_cd *cd)
by
cmd[0] = READ_CAPACITY;
...
the_result = scsi_execute_req(cd-device, cmd, DMA_FROM_DEVICE,
  buffer, 8, NULL, SR_TIMEOUT,
  MAX_RETRIES);
...
cd-capacity = 1 + ((buffer[0]  24) |
(buffer[1]  16) |
(buffer[2]  8) |
buffer[3]);

This code matches the MMC description of the result of SCSI command
25h READ CAPACITY, which is supposed to tell the capacity [...] with
respect to reading operations.
In the context of MMC, reading is not only reading of data, but also reading
of non-data sectors. Thus, READ CAPACITY counts the two non-data sectors
of TAO as readable. (Just not by command 2Bh READ(10), but by BEh READ CD.)

As said, the fault of Linux is not to handle the last two blocks
of CD tracks specially, resp. not to retry by reading single blocks
after reading the last cache tile has failed.
It has to be aware that those two blocks may or may not be part of
the track's payload data. Some try-and-error is inavoidable here.
But the error should not be forwarded to the user and it should not
eat up more than the two questionable blocks.


  Nevertheless, that is a _read_ problem. Dale has a problem with
  write errors.

 Sure, but you asked him to test afterwards by reading back.

I see. Well, if there is a read-ahead bug with DVD then the
checkreading by dd could indeed produce false i/o errors at the
very end of the track.

A safer proposal would then be

  xorriso -outdev /dev/sr0 -check_media use=outdev --

If the medium is DVD+RW or BD-RE then there will be trailing stuff
anyway. One will have again to compute the size of the valid payload
like with my dd proposal, and then use -check_media option max_lba= :

  xorriso -outdev /dev/sr0 -check_media max_lba=1700758 use=outdev --

(-outdev has to be used if the medium content is not an ISO 9660
 filesystem. No writing will happen, because no xorriso command for
 creating or changing an ISO image is used here. Moreover, xorriso
 will not append data to a non-blank medium which it did not aquire
 as input drive. So this is safe.)




  mkudffs and cp.
  But for what, particularly ?

 Random-file-access backups.

That's the reason why i began to develop xorriso.
It can record ACLs and xattr, can register MD5 checksums of medium
and of each single data file, does incremental backups based on
either MD5 or on inode properties, and can checkread its own backups
without the need for seeing the original files.

Example from man xorriso:
  This  changes  the  directory trees /projects and /personal_mail in the
  ISO image so that they become exact copies of their disk  counterparts.
  ISO  file objects get created, deleted or get their attributes adjusted
  accordingly.
  ACL, xattr, hard links and MD5 checksums will be recorded.  Accelerated
  comparison is enabled at the expense of potentially larger backup size.
  Only media with the expected volume ID or  blank  media  are  accepted.
  Files with names matching *.o or *.swp get excluded explicitly.
  When  done  with  writing  the new session gets checked by its recorded
  MD5.

  $ xorriso \
-abort_on FATAL \
-for_backup -disk_dev_ino on \
-assert_volid PROJECTS_MAIL_* FATAL \
-dev /dev/sr0 \
-volid PROJECTS_MAIL_$(date +%Y_%m_%d_%H%M%S) \
-not_leaf *.o -not_leaf *.swp \
-update_r /home/thomas/projects /projects \
-update_r /home/thomas/personal_mail /personal_mail \
-commit -toc -check_md5 FAILURE -- -eject all

  To be used several times on the same medium, whenever an update of  the
  two  disk trees to the medium is desired. Begin with a blank medium and
  update it until the run fails gracefully due to lack of remaining space
  on the old one.
  [...] To apply zisofs compression to those data files which get
  newly  copied  from  the  local  filesystem,  insert   these   commands
  immediately before -commit :
-hardlinks perform_update \
-find / -type f -pending_data -exec set_filter --zisofs -- \

zisofs needs zlib and its development headers at compile time of xorriso.
Linux kernels 

Re: Issues brining BD disks from the command line - write failures

[Thomas Schmitt]

Hi,

 dvdrecord turned into a dead project in 2001 - 6 months after it started.

But no new forks arised since i began to compete with you.


 cdrkit turned into a deas project in May 2007 which is also 6 months after
 the start.

cdrkit is the fork by Debian. Last release was in 2010.
Now look at contemporary Debian ISO images:

  dd if=debian-7.0.0-amd64-netinst.iso count=100 | \
  strings | fgrep XORRISO | sed -e 's/  //g'

says

  XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6, 
LIBBURN-1.2.6 201305041100


export MKISOFS=xorrisofs
growisofs ...
 Why would you like to do that as long as there is the free maintained
 mkisofs?

If not for technical reasons then for the fact that mkisofs has been
thrown out of major Linux distros. (Expelled for social incompatibility
of distro maintainers and you, to be clear.)

Elsewise:
MD5s ? ACLs ? zisofs ? File filters for encryption or compression ?
Support without accusations towards users ?

But of course one does not need growisofs, because xorriso can burn
to all the media which growisofs can burn.
I learned a lot from growisofs. Chapeau towards Andy Polyakov.


  So is libburn, libisofs, libisoburn, cdrskin, and xorriso.

 But these are based on a conceptional mistake: they asume that you need no 
 special privileges to write optical media which is wrong.

My stuff burns CD, DVD, and BD on Linux, FreeBSD, Solaris.
On Linux and FreeBSD it needs rw-permission for the device file.
On Solaris it needs pfexec privileges basic,sys_devices and
r-permission for the device file in /dev/rdsk.

On Linux, you need superuser privileges only for SCSI commands
which are not listed by the kernel as legitimate commands.
All MMC commands are allowed. Also all commands from SPC and SBC,
which are needed for MMC drives.

Not allowed for normal users are the manufacturer-proprietary
commands which are issued by the quality checker QPxTool.


 Cdrtools work on:

Impressive. Chapeau again. (But where shall i get an Apollo MC68000
machine ? They were really nice, back in the early 1990s.)

Most user feedback about libburn comes from Linux.


  The other stuff runs on any X/Open compliant system.
 I have seen similar claims from a  lot of people regarding their software.

Having had a Unix life before Linux, i know how to write portable C.


  xorriso has been ported to the systems to which GRUB2 is ported.

 But it is not needed, as you could use mkisofs...

Not with GRUB2 script grub-mkrescue. I added several features
on request of Vladimir Serbinenko (and killed the GRUB2 fork of
mkisofs before it could get released).
Further Vladimir contributed code for HFS+ hybrid filesystem.

It is about production of MBR, GPT, and APM, for the purpose
of booting from CD and USB stick by BIOS, EFI, and Apple firmware.


 As you see, it makes sense to check software features from time to time.

The users have the choice ... if their distro maintainers
aren't refusing to package cdrtools, that is.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/1082623832021464...@scdbackup.webframe.org

Re: Issues brining BD disks from the command line - write failures

[Thomas Schmitt]

Hi,

 or a bad enclosure maybe?

Rather not. The growisofs error message indicates media problems.


 Current: DVD-R sequential recording

That's a different game ...


 Sense Key: 0x3 Medium Error, deferred error, Segment 0
 Sense Code: 0x0C Qual 0x00 (write error) Fru 0x0

... but quite the same error as with growisofs.


 like there is some sort of issue with DMA access to the drive?

No transport problems to see. The drive dislikes the medium.
(Any medium ?)


 Do I have a coincidence not only getting a brand new dead burner but some
 sort of bus damage to this system?

If the burner is new then complain to the seller and demand
replacement.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/22081623689829268...@scdbackup.webframe.org

Re: Issues brining BD disks from the command line - write failures

[Thomas Schmitt]

Hi,

 The second set of error messages were from cdrtools from the brandonsnider
 ppa.

Obviously cdrecord resp. one of its forks, indeed.

 The error messages are much more verbose -- Not that I'm smart enough to be
 able to really understand them that well.

Actually the beef is the sense code triple 3,0C,00.
It is listed in MMC-6 as
  3 0C 00 WRITE ERROR

More can not be told from the drive's reply which was
  Sense Bytes: 71 00 03 00 00 00 00 0A 00 00 00 00 0C 00 00 00


 Even with cdrtools, I can't get BD media to burn.

I would not use cdrecord or its forks for DVD or BD.
growisofs is fully ok for DVD. It has that error at the end of BD-R
burning, though.

I use my own backends which are based on my libburn:
  cdrskin ... accepts many cdrecord options
  xorriso ... integrated ISO 9660 filesystem generator and burn program.
libburn is tested daily by backups on CD, DVD, and BD media.
Both programs should be available in Linux distros.
cdrskin might be offered as part of package libburn.
xorriso might be offered as part of package libisoburn.


 I can get DVD and CD
 media to burn in the internally attached burner - sometimes.

They become unreliable when they get old. But usually that needs
3 years or longer. I have a little collection of half-dead burners
reaching back ten years.
Traditionally mine fail first on DVD-RW and DVD+R DL.

But a new drive has to burn newly purchased media which it has
in its compatibility list. (The manufacturers often publish a
list of tested media products. That is quite futile because the
seller brands often change their manufacturer.)

In case you experience a successful burn, you should in any case
try whether the medium is fully readablei. A coarse test is:

  Divide the size of the iso image by 2048. E.g. yielding 1700758.

  Let dd copy the computed number of blocks from medium to /dev/null:
dd if=/dev/sr1 bs=2048 count=1700758 of=/dev/null

  If this ends by an i/o error (often near the end of the medium)
  then the burn was not successful.


 In order to remove the BD media as a culprit,

You already tested with DVD-R.
Those must work, or else the drive is ill.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/12603623869371846...@scdbackup.webframe.org

Re: Issues brining BD disks from the command line - write failures

[Thomas Schmitt]

Hi,

Joerg Schilling wrote:

 There are only dead forks from cdrtools - don't use them.

Probably i am the one who is to blame for killing them.

Programmers who consider to fork can as well try libburn
and contact me for feature requests.
That's what happened to Debian's cdrkit. Meanwhile xorriso
produces all their ISOs except for arch powerpc which needs
a HFS filesystem. (I hoped for that arch to die out. But alas,
the virtual machines seem to give it eternal life.)


 Growisofs refers to mkisofs.

One can use growisofs with xorriso's emulation mode xorrisofs too:

  export MKISOFS=xorrisofs
  growisofs ...

It will not do -udf, though. Thus you cannot create an official
Video DVD by xorriso.
On the other hand, one can use xorriso's unique features of
filesystem manipulation, checksumming, compression, encryption,
etc.


 Cdrtools is actively maintained

So is libburn, libisofs, libisoburn, cdrskin, and xorriso.

 and runs on virtially any platform.

libburn works with optical media on Linux, FreeBSD, and Solaris.
The other stuff runs on any X/Open compliant system.i
xorriso has been ported to the systems to which GRUB2 is ported.


 Other writing software does not include mkisofs or similar software.

I do not deem mkisofs to be the best ISO 9660 program. :))
But cdrecord is the best CD writing program, i confess. Chapeau.

We both cannot serve for official Video Blu-ray, btw.
(Even learning all specs would cost 3000 USD, to my knowledge.)

You often told me that mkisofs is not a backup program.
Well, xorriso is.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/4228623856108890...@scdbackup.webframe.org

Re: Issues brining BD disks from the command line - write failures

[Thomas Schmitt]

Hi,

   954499072/250 ( 3.8%) @0.2x, remaining 218:19 RBU 100.0% UBU  12.5%
 WRITE@LBA=720a0h failed with SK=3h/WRITE ERROR]: Input/output error

This is a failure of the drive to write to the medium.
It has nothing to do with your preparations of BDBurn.udf,
but rather with the relation of drive and medium.
I.e. they do not like each other (any more).

The speed is very low. Possibly the drive relocated many
blocks to the Spare Area. Possibibly that Spare area is now
full and further bad blocks could not be replaced by spares.


 CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: Input/output error

This is not the reason of failure. But it could be a known
growisofs bug, that causes an error message at the end of
a burn run. Andy Polyakov, the author of growisofs, stated that
it is harmless. (Some doubts have arised meanwhile, though.)


 Am I creating too large of a file to burn to the media

growisofs is supposed to refuse in that case.
But it started writing and failed early (after only 1 GB).


 I note that growisofs is saying preformatting to 24.8 GB?

This stems from growisofs' habit to format BD-R by default.

To my own experience (with libburn, not with growisofs) BD-R are
more likely to fail if they are formatted. This is contrary to
the theoretical advantages of formatting (Defect Management).


 _any_ help in getting this sorted will be greatly appreciated.

It might help to try writing to unformatted BD-R.

growisofs option  -use-the-force-luke=spare:none  will prevent
formatting of a blank BD-R before writing starts:

  growisofs -speed=1 -use-the-force-luke=spare:none \
-Z /dev/sr1=/mnt/md9/bdburn/BDBurn.udf

My own programs cdrskin and xorriso do not format BD-R by default:

  cdrskin -v speed=1 dev=/dev/sr1 /mnt/md9/bdburn/BDBurn.udf

  xorriso -as cdrecord -v speed=1 dev=/dev/sr1 /mnt/md9/bdburn/BDBurn.udf


-

Since growisofs announced 
  /dev/sr1: Current Write Speed is 2.0x4390KBps.
i assume that the drive does not offer speed 1.
You may inquire the list of speeds by

  dvd+rw-mediainfo /dev/sr1

Look for output lines like
  Write Speed #0:4.0x4495=17980KB/s
  Speed Descriptor#0:00/11826175 R@8.0x4495=35960KB/s W@4.0x4495=17980KB/s
(this is RITEK/BR2 media on Optiarc BD RW BD-5300S)

Or perform
  cdrskin dev=/dev/sr1 --list_speeds
or
  xorriso -outdev /dev/sr1 -list_speeds
and look at the end of their text output.

-

Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/12401623645803380...@scdbackup.webframe.org

Re: Issues brining BD disks from the command line - write failures

[Thomas Schmitt]

Hi,

 :-[ READ FORMAT CAPACITIES failed with SK=3h/ASC=19h/ACQ=00h]: 

3,19,00 is not listed among the official SCSI error codes.

3,x,y means Medium error. The other two components would tell
what kind of medium error. E.g. 3,C0,00 would be Write error.


 :-[ READ BD SPARE INFORMATION failed with SK=5h/INVALID FIELD IN CDB]: 

It looks like the drive refuses to tell anything about BD peculiarities.


  Media ID:  OTCBDR/001

First time i see Optodisc Technology Corporation as manufacturer.
My list says that they are 1x-4x high-to-low media. (The other type
LTH is quite problematic. But HTL should be ok.)

Well, if more than one drive fails with these, then you will have to
try a different medium type. E.g with a different nominal speed
(Optodisc has 1x-6x OTCBDR/002) or from a brand that sells from a
different manufacturer (Brand Verbatim is VERBAT or MBI).

BD-RE are more expensive than BD-R, but usually less error prone.
At least you would surely buy a different medium type.
(And you most surely can revive spoiled BD-RE as soon as you find
 a drive which can handle them.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/32514623672553567...@scdbackup.webframe.org

GNU xorriso 1.2.8 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.2.8
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator. Available
on GNU FTP mirrors as
  xorriso/xorriso-1.2.8.tar.gz

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

* Bug fix: On some drives the request for minimum speed yielded maximum speed

* Bug fix: Reading damaged Rock Ridge data could cause SIGSEGV by NULL.

* Bug fix: -tell_media_space altered the pointers to MD5 of data files
   which stem from a previous session. This produced false
   mismatches with -check_md5_r.

* Bug fix: CD tracks were reported with the sizes of the tracks in the
   first session. Regression introduced with version 1.2.0.

* Bug fix: -check_media use=outdev sector_map= stored TOC of input drive

* Bug fix: -hide hfsplus and -as mkisofs -hide-hfsplus had no effect.
   Thanks to Davy Ho.

* Bug fix: ./configure did not abort if libburn.h or libisofs.h were missing

* New command -move

* New -as mkisofs options -eltorito-id , -eltorito-selcrit


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or 2.6, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

The xorriso release tarball will soon show up at
your local GNU FTP mirror as
  http://ftpmirror.gnu.org/xorriso/xorriso-1.2.8.tar.gz
(see GNU FTP Mirror List http://www.gnu.org/prep/ftp.html )
It is already now available as
  http://www.gnu.org/software/xorriso/xorriso-1.2.8.tar.gz


Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/2278263631029963...@scdbackup.webframe.org

Announcing cdrskin-1.2.8

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.2.8 of
program cdrskin, a burn backend for CD, DVD and BD with a command line
interface compatible to cdrecord.

System requirements:
   Linux with kernel 2.4 or 2.6: libc, libpthread
or FreeBSD : libc, libpthread, IDE and SATA drives need atapicam
or Solaris : libc, libpthread


Changes:

* New option --list_speeds

* -toc and -minfo now report about tracks in the incomplete session

* Bug fix: All CD tracks were reported with the sizes of the tracks in the
   first session. Regression introduced with version 1.2.0 (rev 4552).

* Bug fix: On some drives the request for minimum speed yielded maximum speed


For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html
   http://scdbackup.sourceforge.net/man_1_cdrskin.html

Download:

There is a cdrskin release tarball (containing libburn):

  http://scdbackup.sourceforge.net/cdrskin-1.2.8.tar.gz

and its detached signature file:
  http://scdbackup.sourceforge.net/cdrskin-1.2.8.tar.gz.sig
by which the download may be verified:
  gpg --keyserver keys.gnupg.net --recv-keys ABC0A854
  gpg --verify cdrskin-1.2.8.tar.gz.sig cdrskin-1.2.8.tar.gz

scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org .


cdrskin is also part of the libburn-1.2.8 SVN tag:
  http://svn.libburnia-project.org/libburn/tags/1.2.8
(needs autotools = 1.7 to apply command ./bootstrap)

and of the libburn-1.2.8 release tarball:
  http://files.libburnia-project.org/releases/libburn-1.2.8.tar.gz
(needs only vanilla tools for ./configure ; make)


Post bug reports or requests
either to one of these mailing lists:
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/17711636310444397...@scdbackup.webframe.org

Re: cdrtools 3.0.0 and dvd+rw-tools does not compile

[Thomas Schmitt]

Hi,

 /usr/include/scsi/scsi.h: In function 'scsi_varlen_cdb_length':
 /usr/include/scsi/scsi.h:159: error: 'struct scsi_varlen_cdb_hdr' has no 
 membernamed 'additional_cdb_length'

This looks like a problem with the installed system headers.
/usr/include/scsi/scsi.h is included by burn programs in order to access
Linux system functions for SCSI operations. If there is an error in these
headers then the burn programs are not to blame on the first hand.

There might be the necessity to include other .h files before scsi.h.
But this is not needed with other Linux distros. So i expect you will
find some deviation from the usual Linux header configuration.


 /usr/include/scsi/scsi.h:148: error: expected specifier-qualifier-list
 before 'u8'

I find this type on my system in
  /usr/include/asm-i386/types.h:typedef unsigned char u8;


When you have solved this issue, i would like to propose you also
try to compile my programs cdrskin and xorriso.
Either in their dynamically linked form
  http://www.libburnia-project.org/wiki/Releases
  http://files.libburnia-project.org/releases/libisofs-1.2.6.tar.gz
  http://files.libburnia-project.org/releases/libburn-1.2.6.tar.gz
  http://files.libburnia-project.org/releases/libisoburn-1.2.6.tar.gz
or as standalone binaries
  http://scdbackup.webframe.org/cdrskin_eng.html
  http://scdbackup.webframe.org/cdrskin-1.2.6.tar.gz
  http://www.gnu.org/software/xorriso/
  http://www.gnu.org/software/xorriso/xorriso-1.2.6.tar.gz

Proposals for better portability or other improvements are welcome.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/6503631718201189...@scdbackup.webframe.org

GNU xorriso 1.2.6 released

[Thomas Schmitt]

Hi,

libburnia project is pleased to announce the release of version 1.2.6
of GNU xorriso, a ISO 9660 Rock Ridge filesystem manipulator.

It creates, loads, manipulates and writes ISO 9660 filesystem images with
Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr,
and MD5 checksums.
xorriso can load the management information of existing ISO images and it
writes the session results to optical media or to filesystem objects.
Vice versa xorriso is able to copy file objects from ISO 9660 filesystems
to disk.

A special property of xorriso is that it needs neither an external ISO 9660
formatter program nor an external burn program for CD, DVD or BD but rather
incorporates the libraries of libburnia-project.org .


Novelties:

xorriso has improved its support for frontend programs. As a proof of concept
there is a Tcl/Tk script xorriso-tcltk included in the release tarball.
It needs Tcl and Tk 8.4 or 8.5. Optionally Tcl/Tk package BWidget.
Frontend and xorriso are two separate processes which communicate via pipes.
See also
  http://libburnia-project.org/browser/libisoburn/trunk/frontend/README-tcltk
Screenshot
  http://www.gnu.org/software/xorriso/xorriso-tcltk-screen.gif

Programmers are invited to surpass the GUI quality of xorriso-tcltk by
help of their favorite programming language and widget toolkit.

The language has to do text i/o via standard input and standard output
or via named pipes. Further it has to perform integer arithmetics and
string manipulations.

* Bug fix: SIGSEGV by uninitialized local variable with
   -check_media patch_lba0=on. Regression by version 1.0.6

* Bug fix: -partition_offset 16 kept -isohybrid-gpt-basdat from writing
   MBR partition table entries of type 0xef

* Bug fix: -rollback did not work if indev and outdev were empty

* New -boot_image partition_cyl_align mode all

* New -blank mode prefix force:

* New -osirrox settings blocked and unblock

* New command -lns for creating symbolic links

* New command -toc_of

* New command -msg_op

* New command -launch_frontend

* Proof-of-concept of a GUI frontend program: xorriso-tcltk written in Tcl/Tk.


License: GPLv3+

System requirements:
- GNU/Linux: kernel 2.4 or 2.6, libc, libpthread
- FreeBSD  : libc, libpthread, libiconv, IDE and SATA drives need atapicam
- Solaris  : libc, libpthread
- on other X/Open systems there will be no direct operation of
  CD/DVD/BD drives, but only POSIX i/o which may or may not
  be offered by the system for DVD-RAM, DVD+RW, or BD-RE.

Optional:
  libreadline + libreadline-development
  zlib + zlib-development
  libbz2 + libbz2-development
  on GNU/Linux: libacl + libacl-development
If they were present at compile time, then the optional libraries have to 
be present at runtime, too.


For more info, see http://www.gnu.org/software/xorriso/xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorriso.html
   http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
   http://www.gnu.org/software/xorriso/man_1_xorrecord.html

   http://www.gnu.org/software/xorriso is mirrored at
   scdbackup.sourceforge.net and scdbackup.webframe.org .

Download:

Get GNU xorriso 1.2.6 from 
  http://www.gnu.org/software/xorriso/xorriso-1.2.6.tar.gz
  http://scdbackup.webframe.org/xorriso-1.2.6.tar.gz
  http://scdbackup.sourceforge.net/xorriso-1.2.6.tar.gz
  
Post bug reports or requests to one of these mailing lists:
  mailto:bug-xorr...@gnu.org
  mailto:libburn-hack...@pykix.org
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:scdbac...@gmx.net


 Important Note To Distro Packagers

The GNU ftp server has rejected the release tarball because it is
vulnerable to CVE-2012-3386, an attack that could happen when
make distcheck is performed on a machine with malicious users.
This bug auf autotools is very old.
It was fixed in autotools by
  https://lists.gnu.org/archive/html/automake/2012-07/txtFZ_KlIKoAh.txt
Essential is this change:
  - chmod -R a-w $(distdir); chmod a+w $(distdir)
  + chmod -R a-w $(distdir); chmod u+w $(distdir)

GNU xorriso is affected in these files
  ./Makefile.in:  chmod -R a-w $(distdir); chmod a+w $(distdir)
  ./Makefile: chmod -R a-w $(distdir); chmod a+w $(distdir)

It is unlikely that anybody runs make diskcheck on GNU xorriso,
as this tarball is normally unpacked, built, and installed by end users.
So i decided against rolling back the release and throwing away the testing
effort which was invested into the actual purpose of xorriso.

The next release will hopefully be acceptable to the GNU ftp server again.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/17114608737778218...@scdbackup.webframe.org

Re: growisofs 7.1: problem past first layer on BD-R DL

[Thomas Schmitt]

Hi,

me:
  Do you still have the SCSI logs of cdrskin with BD-R DL ?  If
  so, can it be that there was no command B6 SET STREAMING ?

Dennis Vshivkov:
 I do.  There wasn't.

Well, then i shall fix this by:
  http://libburnia-project.org/changeset/4828

Regrettably, my current test BD-R offers just one speed: 4x. So i
could only check by a debug message that B6h SET STREAMING is now
sent to the drive before burning begins.
(I sent 2x = 8992 kB/s but it still did 4x as was to be expected
 after it listed only one speed descriptor.) 


There is a new cdrskin development tarball uploaded:
  http://scdbackup.sourceforge.net/cdrskin-1.2.5.tar.gz
Timestamp 2012.09.13.090310, MD5 123e3a478c7f5152aa735b02eb46994f.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/29216620007258768...@scdbackup.webframe.org

Re: growisofs 7.1: problem past first layer on BD-R DL

[Thomas Schmitt]

Hi,

 I straced growisofs -dry-run right after the two DL coasters,
 and that showed both the command buffer being sent and the
 response buffer being received.

(And i invested days into implementing an SCSI log.
 That's what i get from not reading manuals.)


 Had I a BD-RE DL, I could test the 32k vs 64k theory with more
 certainty and ease, straight with cdrskin. =)

BD-RE is quite different from BD-R. About as much as DVD-RAM
differs from DVD+R. I assume that the code paths in the firmware
show an according amount of differences.

But of course it would be interesting to see how BD-RE DL
do in comparison to BD-RE SL. The example of BD-R shows that
one has to expect surprises.


 Yes, growisofs reacted to speed=X properly, provided X was
 within drive's abilities.

I will have to investigate. Thanks for reporting.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/28422620085924254...@scdbackup.webframe.org

Re: growisofs 7.1: problem past first layer on BD-R DL

[Thomas Schmitt]

Hi,

Dennis Vshivkov:
  Yes, growisofs reacted to speed=X properly, provided X was
  within drive's abilities.

me:
 I will have to investigate. Thanks for reporting.

Do you still have the SCSI logs of cdrskin with BD-R DL ?
If so, can it be that there was no command B6 SET STREAMING ?

It seems that libburn sends this command only if there is the
text snippet DVD in the current profile. BD profiles seem
to get only the inappropriate comand BBh SET CD SPEED.

That would well explain why the drive prefers to make
its own decision about speed.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/6220620092176593...@scdbackup.webframe.org

Re: growisofs 7.1: problem past first layer on BD-R DL

[Thomas Schmitt]

Hi,

 trying to write BD-R DL for the first time.
 [...]
  $ growisofs -use-the-force-luke=spare:none -speed=4 \
-Z /dev/br genisoimage-options-here...
 [...]
  50.09% done, estimate finish Mon Sep 10 00:43:45 2012
:-[ WRITE@LBA=ba7410h failed with SK=5h/INVALID ADDRESS FOR WRITE]:
 Invalid argument
 [...]
 The error happens after exactly half the capacity plus one
 single 32 KiB block.  The stop point, in 2 KiB block terms:
0xba7410 == 12219408 == 24438784 / 2 + 16

So it looks that for some reason the drive refuses to write to the
second layer.
I can spot in growisofs_mmc.cpp that DVD+R DL get an explicit layer
break position. But this seems not to be true for BD-R DL.
(Especially since BD-R DL have the same profile code as BD-R,
 unlike with DVD+R and DVD+R DL which differ. So growisofs is
 likely to treat both BD-R types exactly the same.)

Regrettably i cannot affort to do own BD-R DL tests.


 (I haven't any BD-RE DL, so the next thing is to try cdrskin,

We'll see what happens then. (I am not overly optimistic.)


 or removing -use-the-force-luke=spare:none)

This would format the blank medium before writing. I have drives and
BD-R media which work together only unformatted. Maybe it is vice
versa with your drive and media: only formatted.
(Equivalent with cdrskin would be option
   blank=format_if_needed
 cdrskin does not format BD-R by default.
)


My own problems were with LTH media (aka organic dye).
I cannot spot in the web, whether VERBAT/IMf can be LTH.
But if your media or their sales box show the the letters LTH,
then you should try to purchase non-LTH for the next test.


 INQUIRY:[PIONEER ][BD-RW   BDR-206D][1.56]

Well, i had a BDR-205 for about 9 months until it went bad
with BD-R in general. In the beginning it wrote to LTH BD-R,
then it spoiled those, later it spoiled non-LTH BD-R too.
I could return it to the merchant and got a Optiarc BD RW BD-5300S
in exchange. This one can write a few sessions to LTH before it
finally spoils them. No problems with non-LTH media.
(I also got an older LG BD-RE GGW-H20L which is fine but flatly
 refuses on LTH media.)

Given the prices of BD burners and BD-R DL, it might be
smart to buy a cheap new burner if blank BD-R DL media are left
after the next round of experiments.
(The Optiarc burner was sold for 60 Euro ~= 80 USD.)


Please keep me informed about any new insight which you gain
about the BD-R DL problem.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/8301619230678374...@scdbackup.webframe.org

Re: growisofs 7.1: problem past first layer on BD-R DL

[Thomas Schmitt]

Hi,

 Well, it'll enable defect management, whatever that really does.

Normally nothing good, except if you really have a small local
damage. To my experience, Defect Management lets media fail
earlier than without. And it makes them slow.

To get full speed with formatted BD-R and with BD-RE use
cdrskin option
  stream_recording=on
which will ask the drive to avoid Defect Management.


 The drive can do both with and without defect management;

My BDR-205 and the Optiarc can do too. But they fail nevertheless
on reasons of indivdual damage or media compatibility problems.
They should work, they think they can, but then ...
... it makes some difference whether the medium is formatted or
not formatted.
But in those situations, drive and media are balancing on the
edge of failure. Sometimes they fall, sometimes they stay up.


 my idea of removing the option and using defect management is based
 on the suspicion that the failing block is indeed problematic on
 the media, and can thus be worked around.

Rather not. The MMC reply code
  5 21 02 INVALID ADDRESS FOR WRITE
clearly says that there is something wrong with the block address of
the SCSI WRITE command.
But growisofs, as any burn program, takes care to increment the
block address in sync with the written amount.
So it would be some firmware error on the first hand.

But well, a mad drive can be deceiving to any degree.

I assume growisofs issued a RESERVE TRACK command before it
began writing. Although i trust it to send the correct parameters,
it might be worth a try to avoid it.
With cdrskin, this can be done by option
  -tao

(-tao is inherited from CD write type TAO. On BD-R and DVD+R it
 just has the effect to omit RESERVE TRACK and rather to write
 with open end.)


 I've never yet seen defect management remap
 anything, that's why I switch it off normally.

I got some BD-RE with replaced blocks. But normally
  cdrskin dev=/dev/sr3 --list_formats
says something like
  BD Spare Area: 0 blocks consumed, 393216 blocks available



I am reading over the BD-R description in MMC-5. 
It seems that dual-layer peculiarities are supposed to be
completely hidden from the host (i.e. the burn program
and its computer).
This differs much from the description of DVD+R DL, where
the opportunity to define the layer break address is explicitely
mentioned.

The command BFh SEND DISC STRUCTURE, which is used for DVD+R DL
layer break definition, is not associated to any of the features
promised by profile 41h BD-R SRM. (Well one could try to apply
growisofs_mmc.cpp function  plus_r_dl_split() to BD-R. It should
do not much harm if it fails. One would have to skip the DVD+R
specific inquiry, though.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/6670619247528590...@scdbackup.webframe.org

Re: [PATCH] growisofs error and dvd+rw-format manual page

[Thomas Schmitt]

Hi,

not being in charge for dvd+rw-tools i am curious enough to read
and comment on the proposed man page.

Honza Horak wrote:
 If  a  DVD-RW medium is in the later one,

Shouldn't that be latter rather than later here ?


 a non-virgin DVD-RW in Sequential Recording
 mode needs to be blanked before writing a new initial session

One should stress that only -blank=full makes a used sequential DVD-RW
capable of performing multi-session. Fast blanked DVD-RW can only do
Disk-At-Once. (Some drives confess the inability, some do not. None can.)

Full blanking lasts as long as full writing.
So formatting DVD-RW is very desirable for multi-session use cases.


 Virgin BD and DVD+RW media  need  to  be  initally  formatted  prior
 usage.

initially rather than initally.

One should replace need by something like may.

DVD+RW get formatted by growisofs as needed when a burn run is desired.
(I once tested that when i had no own stake in operating optical drives.)

BD-R media may get formatted when they are still empty.
I understand growisofs 7.1 does this automatically and unconditionally
when a burn run is desired. (This is not always a good idea, though.)
growisofs_mmc.cpp:
case 0x41:  // BD-R SRM
if ((disc_info[2]3) == 0)  // blank
bd_r_format (cmd);

I also understand that BD-RE get formatted automatically:
case 0x43:  // BR-RE 
if ((disc_info[2]3) == 0)  // blank
bd_re_format (cmd);

I think the main use cases for dvd+rw-format are:
- Formatting DVD-RW to make them overwritable
- Blanking used DVD-RW to make them sequentially writable from scratch
- Formatting BD-R, BD-RE, and DVD-RAM with custom spare area sizes
- Re-Formatting BD-RE and DVD-RAM to change their spare size


 Use -blank=full to change

This sentence looks incomplete.


 Under Linux it will most likely be an ide-scsi device  such as /dev/scd0.

Cough. ide-scsi is dead since kernel 2.6 came out.
Further it seems that sr0 has finally won the battle against scd0.

Maybe one should mention /dev/hda for older Linux 2.6 with IDE/ATAPI
and /dev/sr0 for newer Linux or SATA or USB. (Have there ever been
DVD drives with SCSI bus interface ?)

Overview of drives with suffienct access permissions:
  xorriso -devices
or
  cdrskin --devices


To blank a CD-RW, you have to use another utility, e.g. wodim:
 wodim blank=all -immed dev=/dev/cdrom

Blanking CD-RW in all mode lasts long and is not necessary for the
purpose of re-usability. It might serve privacy and it might revive
media which were spoiled by a bad drive.
Normally one uses fast.

I could offer
  xorriso -outdev /dev/cdrom -blank all|fast|as_needed
or
  cdrskin blank=all|fast|as_needed -immed dev=/dev/cdrom

as_needed is a wizzard-ish mode which decides by itself what must
be done to get a medium which can be written from scratch.


To blank a BD or DVD+RW, run:

One should mention that this is not blanking but simply overwriting
old data to make them (nearly) unreadable.

(The command also applies to formatted DVD-RW and to DVD-RAM.)


Now i am curious whether Andy Polyakov is still around.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/15974613538982640...@scdbackup.webframe.org

Re: BD-RE - can't create UDF on new disc

[Thomas Schmitt]

Hi,

Gary Dale wrote:
 dvd+rw-format -format /dev/sr0
 * BD/DVD±RW/-RAM format utility by ap...@fy.chalmers.se, version 7.1.
 * 25.0GB BD media detected.
 * formatting 59.5%
 root@transponder:/home/garydale# mkudffs /dev/sr0
 Error opening device: Read-only file system
 [...]
 dvd+rw-format -format /dev/sr0
 * BD/DVD±RW/-RAM format utility by ap...@fy.chalmers.se, version 7.1.
 * 24.2GB BD media detected.
 * formatting 0.0%:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN
 PARAMETER LIST]: Input/output error

The 59.6 percent do not necessarily indicate failure.
dvd+rw-format gets these numbers from the drive while it waits
for the SCSI formatting command to finish. Many drives tell unrealistic
progress numbers with blanking or formatting.

More decisive is that no error was reported by dvd+rw-format.
So i would guess formatting succeeded.

You still see the two known problems:

- The drive refuses to re-format an already formatted BD-RE.
  This is not nice. But it is not to blame for your problems
  with the block device driver.

- mkudffs and other clients of the block device driver seem to
  perceive a read-only medium. But it is not read-only on drive level,
  as we can prove by using a burn program to write data onto it.
  Burn programs use the generic SCSI driver, not the block device
  driver.


On August 10 you reported:

 I did another test using system rescue cd. While it gives me
 the same error when I run dvd+rw-format, I note that mkudffs
 complains about multiple extents. 

The second of the two problems showed a change in behavior.
The first one sits obviously in the drive and does not get
influenced by changing the system.

I assume that the second problem sits in the operating system.
So i advise you to boot the rescue system and to check whether
the medium can be written via the block device driver of that
system:

  dd if=/dev/zero of=/dev/sr0 bs=2048 count=1

If this succeeds, then you could try to find out what mkudffs
has to complain. It might then be that the content of the
medium is disliked by mkudffs. If no progress can be made otherwise,
i would flood the medium with zeros and try mkudffs again:

  dd if=/dev/zero of=/dev/sr0 bs=2048 count=11826176

This will last about 40 - 100 minutes with 2x speed. It depends
on the quality of the drive how much effective speed it gets
from the checkreading which it performs on BD-RE while writing.

You can speed it up and get progress messages by letting xorriso
do the writing while it disables checkreading:

  dd if=/dev/zero bs=2048 count=11826176 |
  xorriso -as cdrecord -v dev=/dev/sr0 -nopad stream_recording=on -

 
But the central riddle remains:
Why does the block device driver of a Debian system suddenly decide
that the medium in the drive is incapable of writing ?
This behavior must have had a trigger. When did it begin and what
system changes were done around that time ?


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/19106613787453238...@scdbackup.webframe.org

Re: BD-RE - can't create UDF on new disc

[Thomas Schmitt]

Hi,

Mike Scheutzow wrote:
 do you think that this user
 could be having the well-known udev polls the dvd problem?
 That can cause a block device to appear to be read-only.

Well if it does cause such effects then it is surely worth a
try to disable it.

udev and hald are the natural enemies of burn programs.
We compete for the same hardware and the OS normally does not
care about arbitrating.
Nevertheless, i would have expected that the block device
driver gets more respect by udev.


 Here's one hit from google
 (different symptom, but solution would be the same):
 http://unix.stackexchange.com/questions/1399/dvd-drive-constanly-spins-up-down-when-idle

It advises to try:
  udisks --inhibit-polling /dev/dvd
or
  udisks --inhibit-polling /dev/sr0

Do you have more information about udev causing read-only optical
media ?


Have a nice day :)

Thomas



-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/16981613796066195...@scdbackup.webframe.org

Re: xorriso -simply burn ISO image ?

[Thomas Schmitt]

Hi,

Frank Bauer wrote:
 Since squeeze release is approaching, I might be asked to burn some
 installation CDs, so I wanted to do it the modern way with xorriso.
 [...]
 Well, to be fair, the example is there:
xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed image.iso

 As I understand, this is emulating the good old cdrecord (which,
 again, is fine), but I would be interested in pure xorriso way
 without the need to emulate some other program.

The pure xorriso way would be to compose the image from some
input files and to put it onto the medium on-the-fly.

But here we have a use case which is well served by the cdrecord
gesture. Command -as cdrecord is indeed the only one in xorriso's
command set that flatly writes a data stream into a data track of
an optical medium.
It does this by means of libburn to all commercially available
types of CD, DVD, and BD media. So it is as modern as must be. :))
 

 xorriso -indev /tmp/wheezy.iso -outdev /dev/sr0 -blank as_needed
 -commit -eject out

This would virtually unpack the content of /tmp/wheezy.iso and re-pack
it into a new ISO image that gets written onto /dev/sr0.
Similar to mounting /tmp/wheezy.iso and using the mounted directory
as parameter for xorriso command -add.

But you would have to perform some image manipulation after -indev and
before -commit. Else the program would refuse to write the image.
Most modest would be this command:
  -alter_date a +0 / --
It sets the access time stamp of the root directory to the current time.

Further, the result would not yet contain the boot information that was
added to the original image.
If you only need the capability to boot from CD but not from USB stick,
then you can copy the El Torito boot info from wheezy.iso by performing
command
  -boot_image any keep
before -indev.

In general one may do a lot of manipulations between loading from
-indev and writing by -commit: Delete or overwrite files, change
access permissions, add MD5 checksums, ...

But chances are high that a re-packed wheezy.iso does not benefit
from such creativity (although there surely is power in re-packing
or expanding bootable ISO images).


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/30011613687862171...@scdbackup.webframe.org

Re: BD-RE - can't create UDF on new disc

[Thomas Schmitt]

Hi,

Gary Dale wrote:
 dd if=/dev/zero of=/dev/sr0 bs=2048 count=11826176
 This also fails when booting from sysrecuecd with the same read-only error.

That kills my theory that there went something wrong in the
operating system.

Now i am out of ideas, except diviing into kernel debugging in
order to find out what behavior of the drive makes the systems
believe that the medium is not writable. (Get kernel source,
sprinkle kprintf() over the code parts which implement open(2),
compile, rebooti, try dd, look for messages of you kprintf(),
make theory, plant new kprintf(), ... and so on ...)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/18379613743457923...@scdbackup.webframe.org

Re: BD-RE mount problem

[Thomas Schmitt]

Hi,

  -fd = open(/dev/sr0, O_RDWR);
  +fd = open(/dev/sr0, O_RDWR | O_NDELAY);

 open: fd= 3 , errno= 0
 write: ret= 2048 , errno= 0

This explains why xorriso or dvd+rw-format can open the drive
device file. (The failure to re-format is a different problem.)


 No one in Debian user has been able to shed any light on the problem.

I am not a kernel hacker, but rather a self-proclaimed expert for
optical drives and ISO 9660.

My best guess is that the kernel believes the medium is read-only
(like BD-ROM) and thus refuses any attempt to use it for writing
via the normal POSIX system interface.

But i do not know how to inquire the kernel's view on the medium.
The drive sees a BD-RE and has no scruples to write data to it.
But the kernel seems to see a problem with writing.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Archive: http://lists.debian.org/24165612497463144...@scdbackup.webframe.org