Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #202206 > unrolled thread

Re: Archiving content of a directory on a DVD-R.

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Archiving content of a directory on a DVD-R. peter@easthope.ca - 2018-11-06 18:50 +0100
    Re: Archiving content of a directory on a DVD-R. "Thomas Schmitt" <scdbackup@gmx.net> - 2018-11-06 20:30 +0100
      Re: Archiving content of a directory on a DVD-R. "Thomas Schmitt" <scdbackup@gmx.net> - 2018-11-06 20:50 +0100
        Re: Archiving content of a directory on a DVD-R. Dan Ritter <dsr@randomstring.org> - 2018-11-06 21:10 +0100
          Re: Archiving content of a directory on a DVD-R. "Thomas Schmitt" <scdbackup@gmx.net> - 2018-11-06 21:40 +0100

#202206 — Re: Archiving content of a directory on a DVD-R.

Thanks to all who have replied.

*	From: "Thomas Schmitt" <scdbackup@gmx.net>
*	Date: Sun, 04 Nov 2018 18:48:45 +0100

> Writing the tar stream to DVD-R is a classical use case of cdrecord or wodim.
> So:
> 
>   tar -vcpzf - * | xorriso -as cdrecord -v dev=/dev/sr0 -eject fs=16m -

OK, thanks.  The cdrecord "personality" is used to present a familiar 
legacy syntax? Can the same result be reached using xorriso with no 
personality?

> This will not create a filesystem around the tar archive. 

OK.  The distinction between writing arbitrary data (stream, file, ?) and 
writing a file system hadn't crystalized well.  Software can take an 
action, or not, without direct evidence. To my thinking, all the examples 
in https://www.gnu.org/software/xorriso/ assume an ISO 9660 filesystem.  
No issue for an experienced user but a ready trap for a novice.

Thanks again,                       ... Peter E.

-- 
Message composed and transmitted by software designed to avoid the 
need, overhead and vulnerability of antivirus software.

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202                                  +1 
http://easthope.ca/Peter.html              Bcc: peter at easthope. ca

[toc] | [next] | [standalone]

#202210

Hi,

> The cdrecord "personality" is used to present a familiar 
> legacy syntax?

It helped a lot to get people to trying it out.


> Can the same result be reached using xorriso with no personality?

No. The cdrecord emulation option interface is the only way to achieve
the classical division between ISO producer and optical burn program.

The cdrecord emulation and its enhancements towards cdrecord and wodim
is documented in man 1 xorrecord:
  https://manpages.debian.org/jessie/xorriso/xorrecord.1.en.html
For the mkisofs emulation (which we did not use yet in this thread) see
  https://manpages.debian.org/jessie/xorriso/xorrisofs.1.en.html


> To my thinking, all the examples 
> in https://www.gnu.org/software/xorriso/ assume an ISO 9660 filesystem. 

Most of them, but not all. There is an example for image burning

  Burn an existing ISO image file to medium

   Actually this works with any kind of data, not only ISO images: 
       $ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed image.iso

and an example for piping into xorriso -as cdrecord:

   Perform multi-session runs as of cdrtools traditions

   Between both processes there can be performed arbitrary transportation
   or filtering.
   The first session is written like this: 
   $ xorriso -as mkisofs prepared_for_iso/tree1 | \
      xorriso -as cdrecord -v dev=/dev/sr0 blank=fast -multi -eject - 
   Follow-up sessions are written like this:
   $ dd if=/dev/sr0 count=1 >/dev/null 2>&1
   $ m=$(xorriso -as cdrecord dev=/dev/sr0 -msinfo)
   $ xorriso -as mkisofs -M /dev/sr0 -C $m prepared_for_iso/tree2 | \
     xorriso -as cdrecord -v dev=/dev/sr0 -waiti -multi -eject -
   Always eject the drive tray between sessions.

As one can see, the coordination of both roles is complicated and error prone.
That's why xorriso with its native command set integrates both tasks.
  https://manpages.debian.org/jessie/xorriso/xorriso.1.en.html

(Further, a command set makes possible much a finer definition of the job
 than a heap of options can. You can let xorriso do things before or after
 other things, which sometimes makes a big difference.)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#202212

Hi,

i have to add that the example gesture

  $ dd if=/dev/sr0 count=1 >/dev/null 2>&1

which shall pull in the tray and wait until the drive is ready, does not
work any more. I was using a very fine kernel 2.6 for many years.
Now i am on younger ones which got probably broken 10 years ago by
   https://github.com/torvalds/linux/commit/210ba1d1724f5c4ed87a2ab1a21ca861a915f734

(I am still looking for a kernel developer who would be willing to work
 with me to fix this and a few other bugs or shortcommings. The oldest one
 stems probably from the mid 1990s. It's a matter of social standing and
 of the newest kernel on real iron.) 


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#202213

Thomas Schmitt: 
> Hi,
> 
> i have to add that the example gesture
> 
>   $ dd if=/dev/sr0 count=1 >/dev/null 2>&1
> 
> which shall pull in the tray and wait until the drive is ready, does not
> work any more.

Is this approximately equivalent to `eject -t` ?

-dsr-

[toc] | [prev] | [next] | [standalone]

#202214

Hi,

i wrote:
> >   $ dd if=/dev/sr0 count=1 >/dev/null 2>&1
> > which shall pull in the tray and wait until the drive is ready, does not
> > work any more.

Dan Ritter wrote:
> Is this approximately equivalent to `eject -t` ?

Yes. And equivalently broken. Only burn programs still do wait for the
drive to become ready, because they rely on the sr driver only for a
few ioctls(), especially SG_IO, which performs SCSI command transactions.


Have a nice day :)

Thomas

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web