Re: was once: Samsung DVD writer.

[scdbackup]

Hi,

BTW: What happened to "FreeBSD User Giacomo" and his Samsung DVD writer ?

Any news to report ? A happy ending perchance ?


Bill Davidsen: [about filtering dangerous SCSI commands]
> My suggestion would be to add an ioctl, like SET_SCSI_UNFILTERED, which
> can only be used as root, and which would allow SCSI commands sent a
> device to be persistently set unfiltered.

I understand that would be for programs like firmware
updaters, but not for the vanilla purpose of bringing
data onto an optical disc ?

Because ... if this is intended for daily usage:

I do not think that burning a disc on a desktop should
necessarily require root privileges. Let's leave it to
the sysadmin (or distro) to decide who may burn resp.
may endanger the device by malicious use of normally
harmless SCSI commands. (Like overworking the drive tray
motor ?)

After all, what is gained if one performs daily tasks
as a privileged user ? That only pierces the protection
against absent-minded mistakes and involuntary backdoors.

Actually i try to stay away from any kernel peculiarities
so i do not get addicted to something that might change.
A pointer to a list of forbidden commands would be welcome
thus.

Maybe cdrskin was up to now only tested on totally insecure
systems.  After all i never got reports of the ominous
command filtering interfering with burning. If it prevents
any of libburn's SCSI commands from being executed then it
does this silently and does not prevent burning success.
I would like to know, which commands and cease sending them. :))


libburn SCSI command list (commands in brackets are defined
but not in normal use):
spc.c: 00h, 03h, 12h, 1Eh, 55h, 5Ah,
sbc.c: 1Bh,
mmc.c: 04h, 23h, 2Ah, 35h, 43h, 46h, 4Ah, 
   51h, 52h, 53h, 54h, 5Bh, 5Ch, 5Dh,
   A1h,(AAh),ACh, B6h, BBh,(BEh), 


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Samsung DVD writer.

[scdbackup]

Hi,

Joerg Schilling:
> I do not
> write hacks as other aothors may do but I follow the MMC standard

Just for the records:

libburn is developed according to MMC and i am not aware of
any serious deviations from MMC in dvd+rw-tools either.

libburn still supports some pre-MMC-5 legacies, like mode
page 2Ah "CD/DVD Capabilities & Mechanical Status Page".
In general we handle CD according to MMC-3 with an eye on
MMC-1, DVD are handled according to MMC-5 without much
legacy support intended.

There is no support intended for pre-MMC-1 burners.
Sorry for for any collector of antique IT equipment.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Samsung SH-S183A SATA on VIA VT6420 controller

[scdbackup]

Hi,

Joerg Schilling:
> First an important question: how did you connect that drive?
> You used the sg interface but the drive is most likely ATAPI.
Andreas Klauer:
> > Samsung SH-S183A SATA on VIA VT6420 controller
> > OS is Linux 2.6.18 Debian Etch,

SATA drives nowadays appear as sg,sr,scd.
Seen from outside it is quite like good old ide-scsi.

There is no indication that the new SATA driver code
in general would provoke failures like the ones reported
by growisofs.
But of course the individual kernel version might have
a bug. Shrug. Life on kernel 2.4 is good. Only old bugs.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Samsung SH-S183A SATA on VIA VT6420 controller

[scdbackup]

Hi,

> Verbatim DVD-R 16x 4.7GB.

This cannot be burned without the failed MODE SELECT command.

> drive name: sr1 sr0
> ...
> Can write DVD-R:1   0

Currently i'd count this as a documented case of a
drive lying towards the operating system.


> I just tried a noname blank DVD+RW
> :-[ FORMAT UNIT failed with SK=5h/ASC=24h/ACQ=00h]: Input/output error

5 24 00 = INVALID FIELD IN CDB
(CDB is the command plus parameters which was sent to the drive)

Formatting is supposed to run for a few dozen seconds
in foreground and to then open the way for writing
while continuing in background.


This does not look good.
The drive refuses on about any sincere preparation for
writing. Actually sending some mode pages to learn from
the drive's reaction is a frequent practice even
if one does not burn afterwards.

I assume your failed cdrecord experiments
included an attempt with CD-R[W]. 

The current state is unusual and unhealthy. There is
few hope you will succeed by any burn software.

You will have to strive for replacement of the drive
or for the proof that it works with a different computer
and/or operating system and/or burn software.

If it works in a different environment then one will
have to explore the decisive difference. Interesting.
Open ended, at least. Report any new insight.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Samsung SH-S183A SATA on VIA VT6420 controller

[scdbackup]

Hi,

Andreas Klauer:
> growisofs (7.0.1) says 
> Executing 'builtin_dd if=/root/knoppix5.iso of=/dev/sr1 obs=32k seek=0'
> :-[ MODE SELECT failed with SK=5h/ASC=26h/ACQ=00h]: Input/output error

To my knowledge this is from transport.hxx function page05_setup().
It looks like sending of the write mode parameters page (05h)
has failed. 5 26 00 means INVALID FIELD IN PARAMETER LIST.
(A drive cannot tell it in more detail, i fear.)

Such a mode page has to be sent for DVD-R* family media (and for CD).
What media is loaded ?
Would growisofs work with DVD+RW or DVD+R ?
What do you get from this ?
  cat /proc/sys/dev/cdrom/info


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Error msg.

[scdbackup]

Hi,

Craig Harding:
> I'm tring to write an iso file to a blank'ed dvd-rw disc and I got this
> error. I know that the error msg speaks for itself (medium error), but
> just wondering if it could actually be something else besides my dvd as
> I've used this disc a few times already. It was burning for about 10-15
> minutes before it timed out. Any help appreciated, thanks.

I have experienced similar effects with DVD-RW myself.
They can be very annoying while one is developing own
burning software and unsure wether such is a self-made bug.

My oldest DVD writer (LG GSA-4082B) initially was able to
write to a spindle full of 4x DVD-RW. Then it began to produce
write errors (much like the ones you experience) or OPC errors
on most of those media if they were in sequential state (i.e.
like cdrecord uses them). A few weeks later the ones in
overwriteable state began to die too.
2x DVD-RW from another brand and spindle still work fine.

Much later i bought a NEC ND-4570A and could revive the
unusable 4x DVD-RW. No problems with them at first.
Meanwhile after half a year i experience write errors again.
With old 4x DVD-RW, not with newly bought 4x DVD-RW.
But one of my DVD-ROM drives cannot read the new 4x DVD-RW.
The old LG drive does not burn the new 4x DVD-RW but is
the fastest and most reliable reader for them.
A new PHILIPS USB burner takes those new Verbatim 4x DVD-RW,
gnaws a while on them and then states that there was no media.

I tested this with all programs i know for this purpose:
cdrecord, growisofs, wodim, cdrskin. All the same.
It is not a simple software bug.
It must be related to firmware, drive ageing, media ageing.

So for my backups, i prefer DVD+RW. Some of them die from
time to time, but there is no mass extinction to fear.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: problems writing a large file to DVD+R Double Layer disk

[scdbackup]

Hi,

> Please show the cdrecord -v -minfo output for such a disk.

Re-reading your mail after my first answer i realize
that you might be interested in the output from
appendable and closed multi-session DVD-RW as well.


Have a nice day :)

Thomas


One session and appendable after
  dd if=/dev/zero bs=1M count=500 | cdrskin -v dev=0,0,0 -multi -


$ cdrecord -v dev=0,0,0 -minfo
Cdrecord-ProDVD-Clone 2.01.01a23 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling
TOC Type: 1 = CD-ROM
scsidev: '0,0,0'
scsibus: 0 target: 0 lun: 0
Linux sg driver version: 3.1.25
Using libscg version 'schily-0.9'.
SCSI buffer size: 64512
atapi: 1
Device type: Removable CD-ROM
Version: 0
Response Format: 2
Capabilities   : 
Vendor_info: '_NEC'
Identifikation : 'DVD_RW ND-4570A '
Revision   : '1.02'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: DVD-RW sequential overwrite
Profile: DVD+R/DL 
Profile: DVD+R 
Profile: DVD+RW 
Profile: DVD-R/DL sequential recording 
Profile: DVD-RW sequential overwrite (current)
Profile: DVD-RW restricted overwrite (current)
Profile: DVD-RAM 
Profile: DVD-R sequential recording 
Profile: DVD-ROM 
Profile: CD-RW 
Profile: CD-R 
Profile: CD-ROM 
Profile: Removable Disk 
Using generic SCSI-3/mmc-2 DVD-R/DVD-RW/DVD-RAM driver (mmc_dvd).
Driver flags   : DVD MMC-3 SWABAUDIO BURNFREE 
Supported modes: PACKET SAO
Drive buf size : 1769472 = 1728 KB
Current Secsize: 2048
book type:   DVD-RW, Version > 1.1x -> 1.2 (3.3)
disc size:   120mm (0)
maximum rate:Not specified (15)
number of layers:1
track path:  Parallel Track Path (0)
layer type:  Rewritable Area (2)
linear density:  0.267 µm/bit (0)
track density:   0.74 µm/track (0)
phys start:  196608 (0x3) 
phys end:452607
end layer 0: 0
bca: 0
phys size:...256000
copyr prot type: 0
region mgt info: 0
cpm: 0
cgms:0
last rma sector: 0
application code:2
physical code:   214
last rec address:16621272
part v./ext code:3/1
ind wr. power:   0
wavelength code: 0
write str. code: 00 00 00 00
Manufacturer:   'MCC 01RW4X  '
rzone size: 36
rzone number:   1
border number:  1
ljrs:   0
track mode: 4 copy: 0
damage: 0
reserved track: 0 blank: 0 incremental: 1 fp: 0
data mode:  1
lra valid:  1
nwa valid:  0
rzone start:0
next wr addr:   0
free blocks:0
blocking factor:16
rzone size: 256000
last recorded addr: 255999

Capacity  Blklen/Sparesz.  Type
  256000 2048  Formatted Media
 2297888 2048  Reserved (0)
 2297888   16  Reserved (0)
 2297888   16  Reserved (0)
WARNING: Phys disk size 256000 differs from rzone size 0! Prerecorded disk?
WARNING: Phys start: 196608 Phys end 452607
Disk Is erasable
data type:standard
disk status:  incomplete/appendable
session status:   empty
BG format status: none
first track:  1
number of sessions:   2
first track in last sess: 2
last track in last sess:  2
Disk Is unrestricted
Disk type: DVD, HD-DVD or BD

Track  Sess Type   Start Addr End Addr   Size
==
1 1 Data   0  255999 256000 -1
2 2 Blank  284688 22978872013200  28688

Last session start address: 0
Last session leadout start address: 256000
Next writable address:  284688
Remaining writable size:2013200



Second session, still appendable after another
  dd if=/dev/zero bs=1M count=500 | cdrskin -v dev=0,0,0 -multi -


$ cdrecord -v dev=0,0,0 -minfo
Cdrecord-ProDVD-Clone 2.01.01a23 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling
TOC Type: 1 = CD-ROM
scsidev: '0,0,0'
scsibus: 0 target: 0 lun: 0
Linux sg driver version: 3.1.25
Using libscg version 'schily-0.9'.
SCSI buffer size: 64512
atapi: 1
Device type: Removable CD-ROM
Version: 0
Response Format: 2
Capabilities   : 
Vendor_info: '_NEC'
Identifikation : 'DVD_RW ND-4570A '
Revision   : '1.02'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: DVD-RW sequential overwrite
Profile: DVD+R/DL 
Profile: DVD+R 
Profile: DVD+RW 
Profile: DVD-R/DL sequential recording 
Profile: DVD-RW sequential overwrite (current)
Profile: DVD-RW restricted overwrite (current)
Profile: DVD-RAM 
Profile: DVD-R sequential recording 
Profile: DVD-ROM 
Profile: CD-RW 
Profile: CD-R 
Profile: CD-ROM 
Profile: Removable Disk 
Using generic SCSI-3/mmc-2 DVD-R/DVD-RW/DVD-RAM driver (mmc_dvd).
Driver flags   : DVD MMC-3 SWABAUDIO BURNFREE 
Supported modes: P

Re: problems writing a large file to DVD+R Double Layer disk

[scdbackup]

Hi,

Joerg Schilling:
> I would not believe that this  is true
> Please show the cdrecord -v -minfo output for such a disk.

See post scriptum.

> If the size is not needed in advance in this mode, then grosisofa
> _definitely_ does not write in the best mode.

Well, what is best ?
It works in both modes. Option -dvd-compat allows to control this.

There seem to be issues with old hardware, especially
DVD video players for the livingroom. In that case it is
advised to use DAO (growisofs -dvd-compat , cdrskin -sao ).

I myself have no substantial reports about any trouble
with "-tao" recorded DVD. Possibly there are not enough
users of cdrskin yet.
Meanwhile i dare to finalize DVD+R although growisofs code
warns not to do so. For me it works. For the rest we'll see.


me:
> > Do i miss something ? Is there a way to use
> > Incremental Streaming on DVD-R[W] via cdrecord ?
> > It would come in very handy for scdbackup.
Joerg: 
> There is no such mode, what are you talking about?

MMC-5:
"5.3.11 Incremental Streaming Writable Feature (0021h)
 The Incremental Streaming Writable Feature identifies a Drive that is able
 to write data to a contiguous region, and is able to append data to a
 limited number of locations on the media. On CD media, this is known as
 packet recording, on DVD and HD DVD media it is known as Incremental Recording,
 and on a BD-R disc it is known as SRM recording. The Feature descriptor
 response data is defined in Table 112."

All my DVD drives offer this feature with unused DVD-R[W], with
appendable DVD-R[W] and with DVD-RW which were blanked fully
(e.g.  cdrecord blank=all).


> BTW: it would be intersting to knoe why several people did start own
> CD/DVD writing software project just to learn what they could learn from
> reading my software instead of helping with cdrtools.

My original motivation was a clash between you and some
of your critics in november or december 2005. I began to
fear for the CD burning support in Linux and googled for
background info in order to write a petition to LKML.
My plan was to ask for some simple Linux builtin CD support.
Like with DVD+RW or DVD-RAM.

But i stumbled over libburn and could enhance it to fulfill my
CD needs. Now if you have a thing that burns CD then the wish
to burn DVD is quite natural.
It is an interesting topic and i learned a lot by doing it.

I did not study the CD related code of cdrecord because i wanted
to achieve a technically independent implementation of CD
burning and because there were already enough projects which
maintained programs derived from cdrecord.
Nevertheless, i raise my hat in front of your merits. Your
program cdrecord guided me through that endeavor by setting
the standard to strive for. Many bytes have been copied from
its message output.

Another reason was that libburn already had CD SAO capabilities
and offered enough hints for finding the necessary info in
the SCSI specs.

As for DVD: Joerg, you are too stubborn with them.
Andy Polyakov demonstrated in growisofs that there are more
capabilities in DVD than cdrecord is willing to allow its users.

His tool dvd+rw-mediainfo tells in the headlines of the info
paragraphs what MMC command was used to retrieve. That is very
helpful for the purpose of learning.
To read the source of dvd+rw-tools is less comfortable.
Nevertheless the SCSI commands are clearly recognizable and
commented.  So it is not too hard to find the decisive spots
in the specs.
I have to thank Andy a lot for this rich dumpling of info.

As a contribution to overall knowledge i compiled my findings
in doc/cookbook.txt of cdrskin. It contains summaries of how to
deal with the various types of media. There are lots of pointers
into MMC-5 specs to justify my statements and to provide further
details.


Have a nice day :)

Thomas


-
PS:
Info output with a fully blanked DVD-RW by cdrecord, dvd+rw-tools,
and libburn's demo application telltoc (which comes with cdrskin).

$ cdrecord -v dev=0,0,0 -minfo
Cdrecord-ProDVD-Clone 2.01.01a23 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling
TOC Type: 1 = CD-ROM
scsidev: '0,0,0'
scsibus: 0 target: 0 lun: 0
Linux sg driver version: 3.1.25
Using libscg version 'schily-0.9'.
SCSI buffer size: 64512
atapi: 1
Device type: Removable CD-ROM
Version: 0
Response Format: 2
Capabilities   : 
Vendor_info: '_NEC'
Identifikation : 'DVD_RW ND-4570A '
Revision   : '1.02'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: DVD-RW sequential overwrite
Profile: DVD+R/DL 
Profile: DVD+R 
Profile: DVD+RW 
Profile: DVD-R/DL sequential recording 
Profile: DVD-RW sequential overwrite (current)
Profile: DVD-RW restricted overwrite (current)
Profile: DVD-RAM 
Profile: DVD-R sequential recording 
Profile: DVD-ROM 
Profile: CD-RW 
Profile

Re: problems writing a large file to DVD+R Double Layer disk

[scdbackup]

Hi,

Joerg Schilling:
> The same could be said for e.g. growisofs. Growisofs artificially
> limits the write mode for DVDs to what DVD+R/RW allows ignoring the
> features of DVD-R/RW.

Indeed ? It writes blank DVD-R[W] as DAO with option -dvd-compat
and it writes them as Incremental Streaming (32 kB fixed packet)
elsewise. Reasons not to use Incremental Streaming with DVD-RW:
- they are formatted to Restricted Overwrite,
- they are fast-blanked, which allows DAO only.
Usually the media is left appendable after Incremental Streaming,
but on appendable DVD-RW growisofs -dvd-compat causes closing
after the session is written.


>  The size is only "unneded"
> in case you use the less compatible packet writing mode. Cdrecord
> by default implements the write mode with the best read-compatibility.

Do i miss something ? Is there a way to use
Incremental Streaming on DVD-R[W] via cdrecord ?
It would come in very handy for scdbackup.

Don't get me wrong. I am sincerely interested in learning
about cdrecord's capabilities.
I just tested with cdrecord-2.01.01a23 on a blank DVD-RW

  dd if=/dev/zero bs=1M count=500 | cdrecord -v dev=0,0,0 -packet -

and got 

  cdrecord: Drive does not support TAO recording.
  cdrecord: Illegal write mode for this drive.

The same with
  dd if=/dev/zero bs=1M count=500 | cdrecord -v dev=0,0,0 -tao -

With
  dd if=/dev/zero bs=1M count=500 | cdrecord -v dev=0,0,0 -
i get
  cdrecord: Track 1 has unknown length.
  cdrecord: Use tsize= option in SAO mode to specify track size.


Testing cdrskin on the very same media:
  dd if=/dev/zero bs=1M count=500 | cdrskin -v dev=0,0,0 - 
This works.
Also working:
  dd if=/dev/zero bs=1M count=500 | cdrskin -v dev=0,0,0 blank=all -multi -
  dd if=/dev/zero bs=1M count=500 | cdrskin -v dev=0,0,0 -multi -
producing two recognizable sessions on the media
which stays appendable:
  Media content: session  1  track 1 data   lba: 000:02:00
  Media content: session  1  leadoutlba:25600056:55:25
  Media content: session  2  track 2 data   lba:28468863:17:63
  Media content: session  2  leadoutlba:540688   120:11:13
  Media msinfo : mkisofs ... -C 284688,548384
Much like on CD. Linux mount as of kernel 2.4 recognizes
the last session as the thing to mount (and to fail with,
in this case). One could use the -C values to produce
a third session in mountable ISO-9660 format.

If there is a way to do this with cdrecord on DVD-R[W] then
please give me an example how to.


> I advise to use cdrecord for production quality media...

Indeed my advise to write the single large file rawly
would match well the characteristics of cdrecord -sao :

  cdrecord -v dev=... -sao /my/large/file
 
This advise stays valid in case no other suitable formatting
can be found.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: problems writing a large file to DVD+R Double Layer disk

[scdbackup]

Hi,

Kish Shen:
> Anyway, it [mkisofs] again said my file is too large and ignored it.

Even if you can talk some mkisofs into formatting a
file system with a file >= 2 GB, even then you might
have difficulties to read that file on arbitrary
computer systems.

You'll have to split your file or use a large-file capable
archiver rather than mkisofs.
To my experience Joerg's program "star" is well suited.

If it is about a single file, you may also write it
on media flatly and memorize the size (i.e. write it
on the media's upside with a pen).
To write:
  growisofs -Z /dev/sr1=/my/fat/file
To get it back:
  dd if=/dev/dvd bs=2048 count=... of=/my/copy/on/disk 
with count=... giving the memorized number of blocks.


Joerg Schilling:
> There is nothing like "speudo SCSI" CD/DVD writers only work with SCSI
> commands.

That is true of course.
The command set is always SCSI as described in sub specs
SPC, SBC, MMC.

I meant :
Appearing under Linux as /dev/sg and /dev/sr and not as /dev/hd.
Pseudo-Linux-SCSI. Ok ?


me:
> > Programs growisofs or cdrskin are to prefer for that.
Joerg Schilling:
> The preferred program still is cdrecord.

But not for piping onto DVD and not for multi-session on DVD.

Joerg, i do not want to diminish your merits about burning.
Nevertheless, currently cdrecord imposes too much restrictions
which cannot be justified on the level of MMC-5 specs.

growisofs proves it since years, i proved it this year:
With single layer media no predicted size of the logical track
is needed except for DVD-RW treated by e.g. cdrecord blank=fast.
But cdrecord blank=all yields fully capable DVD-RW.

One can justify the SCSI gestures of growisofs by the MMC-5
specs. I looked at what Andy Polyakov's program does, then i
learned in the specs what this means and then i did my own
implementation of those specs (not of growisofs code).
It works on various DVD drives in the age of 3 to 0 years.
It is written down in
  http://libburnia.pykix.org/browser/libburn/trunk/doc/cookbook.txt?format=raw
paragraphs
- Overwriteable DVD Cookbook (DVD-RAM, DVD+RW, DVD-RW)
- Sequential DVD-R[W] Cookbook
- DVD+R Cookbook (still emerging)
with lots of references into the SCSI specs.

Be invited to read it and to point me to any errors.


> For double layer media, you _need_ to know the size in advance in 
> order to be able to set the layer break at the right place.
> If you do not know this, please do not give advise

Well, i did not burn double layers yet, nor did i find anybody
who is willing to try it. Kish Shen wants to use DVD+R/DL.
Maybe he got one left to waste for the progress of science.

Actually i advise to use growisofs for production purposes
with DVD+R/DL.
Default cdrskin refuses to risk those expensive media.


Anybody who is ready to risk a DVD+R/DL or DVD-R/DL media is
hereby called up to pipe the output of some formatter
(e.g. afio, star, ...) into the stdin of growisofs.
More than 4.7e9 bytes, of course. Do not use ISO-9660 format
because growisofs will recognize its size from the data.

Then let's see wether it works. I bet on Yes. :))


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: problems writing a large file to DVD+R Double Layer disk

[scdbackup]

Hi,

Kish Shen: 
> use it -- can I use it to create a backup of my file(s)?i
> My DVD rewriter is a USB device, and not
> a SCSI device, and I am not sure what the device number and LUN etc.
> are for it (I only know that /dev/sr1 and /dev/scd1 both map to it).

As it is pseudo-SCSI, try this

  cdrecord -scanbus 


> Should I do something like:
> mkisofs -R /master/tree  |  cdrecord  speed=2  dev=2,0

There's a track source missing with cdrecord.
For CD media, '-' would be ok.  With DVD media, piping
becomes cumbersome.

Programs growisofs or cdrskin are to prefer for that.
Both are able to pipe a data stream of unpredicted
size onto DVD.
cdrskin is untested with double layer media, so you will
have to be adventurous or use growisofs.

Usually growisofs does its own internal mkisofs piping.
But if you want to use it as a plain DVD writer, try this:

  mkisofs -R /master/tree  |  growisofs -Z /dev/sr1=/dev/fd/0

(/dev/fd/0 is one way to say "standard input" as file address.)


With cdrskin and single layer media, the same would be: 

  mkisofs -R /master/tree  |  cdrskin -v speed=2 dev=/dev/sr1 -multi -

Testers for double-layer media are wanted.
Gallant wealthy users please contact me. :))

If you are interested in multi-volume backup on CD or DVD, 
i got a tool for that: scdbackup.


Joerg Schilling:
> Once cdrecord will support multi-border for DVD+R, it will be done in the 
> official way, it depends on whether growisofs does the same.

At least according to MMC-5 there is not much danger that
multi-session on DVD+R will be incompatible between the
programs which are capable of it.

We all close a track before we start the next one and thus it
makes hardly a difference in the result wether we reserve the
track size in advance or wether we just write away.
Decisive is rather the CLOSE TRACK/SESSION function which
is used at the end of a track. 010b keeps appendable,
101b and 110b finalize the disc. (mmc5r03c.pdf, 6.3.3.4)

growisofs obviously refuses to finalize any DVD+R.
So does cdrskin-0.3.4. In the development version cdrskin-0.3.5
DVD+R get finalized by 101b unless option -multi is present.
I.e. just like with CD-R[W] or DVD-R[W].
Maybe i learn why growisofs has this reluctance. Cautious
cdrskin-0.3.5 users might want to add -multi to any run on DVD+R
until then.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Samsung DVD writer.

[scdbackup]

Hi,

Isaia Luciano wrote:
> > cd0:  device Removable CD-ROM SCSI-0 

Google for this type and you will find a surprising
high density of cries for help among all the usual
best-price offers.


> > If I use the comand whith a dvd+rw : dvd+rw-format /dev/cd0
> > Input/output error and on the consul: umass0: 
> > Unsupported ATAPI command 0x46. 

Joerg Schilling wrote:
> I see no relation to cdrecord..

There seems to be rather a relation to drive weirdology.

A GET CONFIGURATION command should succeed if the
drive is ready to do any work.
"Unsupported ATAPI command 0x46" looks much like
a message from operating system resp. a ATA controller.
If the drive's firmware would dislike 46h, i'd expect
rather a complaint about "SCSI" or "MMC".

But the thing is supposed to be connected via USB
and not via ATA/IDE. Does BSD have a usb-atapi
emulation ? 


> > With another external drive LG this is OK.

Same operating system installation ?
That would put all suspicion on the individual drive.

Do you have an opportunity to connect the drive
to a computer with Linux ? Would dvd+rw-mediainfo
fail there too ?


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Announcing Linux CD/DVD burn program cdrskin-0.3.4

[scdbackup]

Hi,

be invited to try my program cdrskin, a burn backend for
CD and DVD with a command line interface that is compatible
with cdrecord's main gestures for CD.

System requirements:
  Linux with kernel 2.4 or 2.6.
  With kernel 2.4 an ATA drive has to be under ide-scsi control,
  with kernel 2.6 it shouldn't.
  Tests have been made with drives on SCSI, ATA, SATA and USB.
  Drive adresses suitable for cdrecord or wodim are supposed to
  work with cdrskin, too.

Freshly released is version 0.3.4 which offers, with the
usage characteristics known from cdrecord with CD media,
on the following media types:
  CD-R[W]  : -tao, -sao, -multi, [blank=], -dummy, -data, -audio
  DVD-R[W] : -tao, -sao, -multi, [blank=], -dummy, -data
  DVD+R: -tao, -multi, -data
  DVD+RW   : -tao, -data
  DVD-RAM  : -tao, -data
  DVD-RW after blank=format_overwrite : -tao, -data

See also
  http://scdbackup.sourceforge.net/man_1_cdrskin.html
  http://scdbackup.sourceforge.net/cdrskin_eng.html
  http://scdbackup.sourceforge.net/README_cdrskin

License:
  GPL


Download is offered in several variations. Any of them provides
a complete cdrskin program.

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

cdrskin is part of the libburn-0.3.4 release tarball:
  http://libburnia-download.pykix.org/releases/libburn-0.3.4.tar.gz
(needs only vanilla tools for ./configure ; make)

There are also a cdrskin release tarball (containing libburn):
  http://scdbackup.sourceforge.net/cdrskin-0.3.4.pl00.tar.gz
and single binaries in tar wrappers:
  http://scdbackup.sourceforge.net/cdrskin_0.3.4.pl00-x86-suse9_0.tar.gz
  http://scdbackup.sourceforge.net/cdrskin_0.3.4.pl00-x86-suse9_0-static.tar.gz
The latter is supposed to run on most systems with kernel 2.4 or 2.6.

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


Post bug reports or requests
either to the libburnia ticket system:
  http://libburnia.pykix.org/newticket
or to one of these mailing lists:
  mailto:[EMAIL PROTECTED]
  mailto:cdwrite@other.debian.org
or directly to me:
  mailto:[EMAIL PROTECTED]


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: growisofs DVD-R[W] DAO can fail with piped input

[scdbackup]

Hi,

> > For cdrskin i decided to:
> > - disallow undefined track size with DVD-R[W] DAO
> >   and demand a recognizable file size or an explicit
> >   track size.
> Just for reference, Joerg and I had a discussion of this, related to 
> doing remote backups where the ISO image is generated on one machine and 
> piped to cdrecord on another. It appears to have the same limitations,

Those are the hard limitations of DAO write mode
on DVD-R[W] as it seems.
Although the specs leave a little hope for a
pro-forma track reservation with insufficient
size, my drives don't allow this.
DAO means fixed image size. :(

But there is still Incremental Streaming ! :))
TAO-like multi-session writing on DVD-R[W]. I love it.
Only my 2.4 kernel driven DVD-ROM dislikes.
A DVD-ROM under kernel 2.6 and my ide-scsi driven
burners have no problem with incremental multi-session
DVD-RW. The mount command of my kernel 2.4 finds the
last session on DVD-RW and mounts it.
A drawback is that the DVD-RW media have to be new
or blanked fully. Minimally blanked DVD-RW do only DAO.

There is also Restricted Overwrite formatting
for DVD-RW (not for DVD-R) which allows no traditional
multi-session but needs no predicted size and no
blanking.

If the drive-media compatibility of DVD-RW wasn't such
a mess, i would declare it my favorite media.
But for the sake of reliable burn success i stay with
DVD+RW for my backups.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

cdrecord: unclear error messages with non-blank DVD-RW

[scdbackup]

Hi Joerg,

while exploring DVD burning in theory and practice i
stumbled over some user-confusing behavior of cdrecord
in cases where a DVD-RW media is not in a suitable state.

With written, non-appendable media it begins to issue
error messages about CD and "100 minutes".

With appendable media it runs into an SCSI error by attempting
53h RESERVE TRACK although feature 002Fh "DVD-R/-RW Write"
is not current.


Have a nice day :)

Thomas


Details:

Closed media produced by cdrecord -sao :

$ cdrecord -v dev=0,0,0 driveropts=burnfree -eject -sao /dvdbuffer/fertig.iso
Cdrecord-ProDVD-Clone 2.01.01a23 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling
TOC Type: 1 = CD-ROM
scsidev: '0,0,0'
scsibus: 0 target: 0 lun: 0
Linux sg driver version: 3.1.25
Using libscg version 'schily-0.9'.
Driveropts: 'burnfree'
SCSI buffer size: 64512
atapi: 1
Device type: Removable CD-ROM
Version: 0
Response Format: 2
Capabilities   : 
Vendor_info: '_NEC'
Identifikation : 'DVD_RW ND-4570A '
Revision   : '1.02'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: DVD-RW sequential overwrite
Profile: DVD+R/DL 
Profile: DVD+R 
Profile: DVD+RW 
Profile: DVD-R/DL sequential recording 
Profile: DVD-RW sequential overwrite (current)
Profile: DVD-RW restricted overwrite (current)
Profile: DVD-RAM 
Profile: DVD-R sequential recording 
Profile: DVD-ROM 
Profile: CD-RW 
Profile: CD-R 
Profile: CD-ROM 
Profile: Removable Disk 
Using generic SCSI-3/mmc-2 DVD-R/DVD-RW/DVD-RAM driver (mmc_dvd).
Driver flags   : DVD MMC-3 SWABAUDIO BURNFREE 
Supported modes: PACKET SAO
Drive buf size : 1769472 = 1728 KB
FIFO size  : 4194304 = 4096 KB
Track 01: data   125 MB
Total size:  125 MB = 64062 sectors
Current Secsize: 2048
WARNING: Phys disk size 1077264 differs from rzone size 0! Prerecorded disk?
WARNING: Phys start: 196608 Phys end 1273871
cdrecord: Data will not fit on any disk.
cdrecord: Cannot write CD's >= 100 minutes.


Appendable media produced by growisofs or cdrskin :

$ cdrecord -v dev=0,0,0 driveropts=burnfree -eject -sao  /dvdbuffer/fertig.iso
Cdrecord-ProDVD-Clone 2.01.01a23 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling
TOC Type: 1 = CD-ROM
scsidev: '0,0,0'
scsibus: 0 target: 0 lun: 0
Linux sg driver version: 3.1.25
Using libscg version 'schily-0.9'.
Driveropts: 'burnfree'
SCSI buffer size: 64512
atapi: 1
Device type: Removable CD-ROM
Version: 0
Response Format: 2
Capabilities   : 
Vendor_info: '_NEC'
Identifikation : 'DVD_RW ND-4570A '
Revision   : '1.02'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: DVD-RW sequential overwrite
Profile: DVD+R/DL 
Profile: DVD+R 
Profile: DVD+RW 
Profile: DVD-R/DL sequential recording 
Profile: DVD-RW sequential overwrite (current)
Profile: DVD-RW restricted overwrite (current)
Profile: DVD-RAM 
Profile: DVD-R sequential recording 
Profile: DVD-ROM 
Profile: CD-RW 
Profile: CD-R 
Profile: CD-ROM 
Profile: Removable Disk 
Using generic SCSI-3/mmc-2 DVD-R/DVD-RW/DVD-RAM driver (mmc_dvd).
Driver flags   : DVD MMC-3 SWABAUDIO BURNFREE 
Supported modes: PACKET SAO
Drive buf size : 1769472 = 1728 KB
FIFO size  : 4194304 = 4096 KB
Track 01: data   125 MB
Total size:  125 MB = 64062 sectors
Current Secsize: 2048
Trying to clear drive status.
cdrecord: Drive needs to reload the media to return to proper status.
WARNING: Phys disk size 524288 differs from rzone size 0! Prerecorded disk?
WARNING: Phys start: 196608 Phys end 720895
Starting to write CD/DVD at speed 4 in real SAO mode for single session.
Last chance to quit, starting real write0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
BURN-Free is OFF.
Turning BURN-Free on
cdrecord: Input/output error. reserve_track_rzone: scsi sendcmd: no error
CDB:  53 00 00 00 00 00 00 FA 3E 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 30 05 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x30 Qual 0x05 (cannot write medium - incompatible format) Fru 0x0
Sense flags: Blk 0 (not valid) 
cmd finished after 0.001s timeout 100s
cdrecord: Cannot open next track.
Writing  time:0.030s
Average write speed 999.0x.
Fixating...
Fixating time:0.000s
BURN-Free was not used.
cdrecord: fifo had 64 puts and 0 gets.
cdrecord: fifo was 0 times empty and 0 times full, min fill was 100%.

-
Reproducability info:

Appendable DVD-RW emerge from media which offer feature 0021h.
On my drives this demands appendable, new or fully blanked media.
  cdrecord blank=all
or
  dvd+rw-format -blank=full
or
  cdrskin blank=all

To be burned by
  growisofs -Z /dev/... /some/files
or
  cdrskin dev=/dev/... -multi image.iso

To be closed by
  growisofs -dvd-compat -M /dev/... /more/files
or
  cdrskin de

growisofs DVD-R[W] DAO can fail with piped input

[scdbackup]

Hi Andy,

while learning how dvd+rw-tools is doing its work,
i meanwhile came to DVD-RW Disk-At-Once where i
discovered a processing path in the code which
avoids the track reservation. Another related path
seems to reserve a size that might be too small.

I tested those use cases with growisofs 7.0. It looks that
at least my drives do not appreciate what growisofs
is doing. (Are there drives known which would do ?)

The code which made me think is in growisofs_mmc.cpp :
if (is_dao && leadout)
minus_r_reserve_track(cmd,leadout);


Before each burn the DVD-RW was treated with
  $ dvd+rw-format -blank /dev/sr0

Submitting a logical track of unspecified length
seems indeed to circumvent 53h RESERVE TRACK and
next it fails:

  $ dd if=/dev/zero bs=2048 count=50 | \
growisofs -use-the-force-luke=dao -Z /dev/sr0=/dev/fd/0
  ...
  /dev/sr0: engaging DVD-RW DAO upon user request...

Here function  minus_r_reserve_track()  with a disk file
as source would state something like
  /dev/sr0: reserving 50 blocks
In this case it doesn't, but rather states as next lines:

  /dev/sr0: "Current Write Speed" is 4.1x1352KBps.
  :-! "COMMAND SEQUENCE ERROR"@LBA=0h. Is media being read?
  :-! the LUN appears to be stuck at 0h, retrying in 5 secs...

I waited about a minute but no progress was visible
with the subsequent retries.

"Command sequence error" looks much like 53h RESERVE TRACK
is mandatory with DAO DVD-RW. I believe the first 2Ah WRITE
came when the drive was still awaiting some setup.

Looks like this would happen with any piped input which is
not in ISO-9660 format (E.g. afio, star) and has no explicit
size given via -use-the-force-luke.


Next there is a problem if a ISO-9660 header does not predict
the full length of the data stream.

The specs stay undecided. mmc5r03c.pdf  6.31.2.4 :
"Based upon the currently mounted media, it is possible
 for the Host to request a Reservation Size that is too small."

By chance i got a real use case for such ISO images:

My backup project appends checksum data to its ISO-9660 images.
With Incremental Streaming this only has the funny effect of
getting reported more than 100% "done" with the pacifier messages.
But with DAO :

  $ dd if=/dvdbuffer/fertig.iso | \
growisofs -use-the-force-luke=dao -Z /dev/sr0=/dev/fd/0
  ...
  /dev/sr0: engaging DVD-RW DAO upon user request...
  /dev/sr0: reserving 64046 block, warning for short DAO recording
  /dev/sr0: "Current Write Speed" is 4.1x1352KBps.
  :-? the LUN appears to be stuck writing LBA=fa30h, keep retrying in 23ms

Again, no progress with the retries. I pressed CTRL+C
and after some due waiting time, the process ended.

The file  fertig.iso  is 32313 bytes larger than the
reserved track size of 64046 * 2048. 

When giving the disk file as source, everthing is ok:
  $ growisofs -use-the-force-luke=dao -Z /dev/sr0=/dvdbuffer/fertig.iso
  ...
  /dev/sr0: reserving 64061 block, warning for short DAO recording
  ...


Since DAO is avoidable only if i do
  dvd+rw-format-blank=full
it is not purely deliberate user risk but could also bite me
if i inadvertedly use such media.

(I did not test yet the situation where a track source is smaller
than announced by the ISO-9660 header.)


For cdrskin i decided to:
- disallow undefined track size with DVD-R[W] DAO
  and demand a recognizable file size or an explicit
  track size.
- truncate the data stream to the reserved size
  and eventually indicate failure by its exit value.
- pad up tracks where the data source does not deliver
  the announced size.
So DVD-R[W] DAO will behave like single track CD SAO.


Andy: Many thanks for all the info which i gained from
dvd+rw-tools meanwhile.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Need help

[scdbackup]

Hi,

> I tried "cdrecord -scanbus". But I got the following error message.
> "cdrecord: No such file or directory. Cannot open SCSI driver."
> Can you help me please?

Looks like you stirred up other much older quarrels.
These quarrels are the reason why we got some wealth of
cdrecord compatible programs. Better too many than too few.

The original:
You might expect help from Joerg Schilling, the author of
cdrecord, if you use his newest release, from 
  ftp://ftp.berlios.de/pub/cdrecord/alpha
To my knowledge current is:
  ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a23.tar.gz
(For some reason this address does not work for me currently.
traceroute ends at funnel.fokus.fraunhofer.de )
Proper problem reports are indeed on topic here
  cdwrite@other.debian.org
but see below for some hints.

Project cdrkit:
cdrkit contains program wodim which stems from cdrecord
and is therefore very very compatible. 
  http://cdrkit.org
Current seems to be
  http://cdrkit.org/releases/cdrkit-1.1.1.tar.gz
I guess problem reports can be submitted to
  [EMAIL PROTECTED]

My own effort:
cdrskin is the cdrecord compatibility wrapper of libburn
  http://scdbackup.sourceforge.net/cdrskin_eng.html
current is (i'm sure)
  http://scdbackup.sourceforge.net/cdrskin-0.2.6.pl02.tar.gz
Bug reports and requests can be mailed to
  [EMAIL PROTECTED]
or submitted at
  http://libburnia.pykix.org/newticket


If you picked the recent release of one of above projects
and then still have the problem: please give some info wether
you were superuser and on what operating system ...

If it is Linux, one reason might be the lack of sg devices.
So the output of this could be interesting:
  ls -l /dev/sg[0-9]*
  lsmod | grep sg


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Oddness piping mkisofs into recent cdrecord versions

[scdbackup]

Hi,

Bill Davidsen:
> I can't replicate the "no TAO" with a CD,

This is the best outcome we can wish for.
A non-TAO CD burner would be very annoying.


> Question: what does "-dvd-compat" really do?

You mean in growisofs ? That's always interesting
to read :))

On the first hand it sets variables "poor_man" and
"dvd_compat".

poor_man is still a bit of a riddle to me, because
it is set to 1 at several occasions and its usage is 
manifold. It seems to apply to situations where a
real burner device is the target. All my use cases
with growisofs have (poor_man!=0).
Etymologcally "poor man" might stem from Andy's
2.4 kernel patch (= rich man, has block device suitable
to dd to media) and the "builtin-dd" for poorly
courageous people like me who prefer to run a
consumer kernel. From growisofs.c:
  * - "poor-man" support for those who don't want to recompile the
  *   kernel;


My (probably incomplete) idea of dvd_compat is that it
causes a DVD+RW to get formatted thoroughly ("de-iced"),
that it forces non-multisession for most other DVD+/-
media and then closes these.
It also does _something_ with Double Layer DVDs.

I refer to document mmc5r03c.pdf . Current is 
  http://www.t10.org/ftp/t10/drafts/mmc5/mmc5r04.pdf
It seems that MMC-6 has started recently.
Andy refers to MMC-4 in some of his program remarks.

dvd_compat:

- There is some some reservation against it in growisofs.c:
/* never finalize disc at multi-sessioning DVD±R recordings...
/* ... except when filling the media up:-)

- With DVD+RW it forces 04h FORMAT UNIT with format type 
  26h and restart bit. I.e. an eventually interrupted
  format from previous writing is resumed even if the
  burn job would fit into the already formatted area.
MMC-5, 6.5.4.2.14

  It prevents the stop of de-icing via 5Bh CLOSE TRACK/
  SESSION, close function 000b "Quick Stop Background Format"
  at the end of a DVD+RW burn. De-icing makes addressable
  areas on the media which are yet unused.
MMC-5, 3.1.17
MMC-5, 6.3.3.6.2
  
- With DVD+R there is some deprecation of dvd_compat:
* - 'growisofs -M /dev/cdrom=/dev/zero', this is basically a counter-
[...]
* - disable -dvd-compat with -M option and DVD+R, advice to fill up
*   the media as above instead;

  If set, it disables multi-session in mode page 5
  and sets the write type to SAO.
MMC-5, 7.5

  At the end of a DVD+R write it causes 5Bh CLOSE TRACK/
  SESSION, close function 110b "Finalize".
MMC-5, 6.3.3.4.5
  rather than 010b "Close Session"
MMC-5, 6.3.3.4.3

- With DVD+R DL : close function is 101b "Finalize with
  Minimal Radius"
MMC-5, 6.3.3.5.5
  rather than 010b "Close Session"
MMC-5, 6.3.3.5.3

  if (profile==0x2B && next_track==1 && dvd_compat && leadout)
 plus_r_dl_split((cmd,leadout);
  which issues a command BFh SEND DISC STRUCTURE.
MMC-5 6.43 (i did not read this yet)

- With sequential DVD-R* and multiple -dvd-compat, variable
  "is_dao" gets set to 1. It is set automatically if feature
  0021h "Incremental Streaming" is not offered by the drive.
  (MMC-5: "On CD media, this is known as packet recording")
  is_dao causes write type 02h "SAO"
MMC-5, 7.5.4.9
  and other behavioral modifications, like suppressing
  5Bh CLOSE TRACK/SESSION with close function 001b 
  "Close a Logical Track".
MMC-5, 6.3.3.3.2
  (I did not get to sequential DVD recording yet. Still
   exploring DVD-RW Restricted Overwrite where i try to
   make an own theory how to manage sessions. Somehow i
   do not recognize the growisofs doings in the specs -
   although growisofs works well and my own derived sketch
   seems to work too ...)

  It disables multi-session with DVD-R DL.
MMC-5, 7.5

- Various text messages talk of closing "disc" rather
  than closing "session".


Hey Andy: How good is my score ?
How much did i miss and what did i misunderstand ?


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Oddness piping mkisofs into recent cdrecord versions

[scdbackup]

Hi,

Bill Davidsen:
> > for some reason cdrecord 
> > thinks the TAO capability is missing. As noted, growisofs has no such 
> > problem,
Joerg Schilling:
> DVDs do not support TAO

Indeed. But they constitute a nice freak show of
write modes and usage peculiarities.

DVD-RAM, DVD+RW and DVD-RW "Restricted Overwrite"
are nearly random access read-write devices.
All three can easily perform TAO-like recording of
a single track and session.


Joerg:
> AFAIK, growisofs does not support multi-session but implement a fake...
> cdrecord will soon support real multi-session for DVDs.

I would not call a "fake" growisofs' method to produce
multi-session ISO-9660 on media which have no sessions.
It is a great workaround and well adapted to the
circumstances.
Now you made me curious about how cdrecord will do the
-multi and -msinfo thing with above media types so that
mount is able to find the most recent session.


> You _need_ to run mkisofs twice in case you do not
> create an intermediate file.

With contemporary cdrecord on DVD: regrettably yes.

But it is not needed with cdrecord, wodim or cdrskin
on CD (provided -tao does work).
It is not necessary with growisofs on DVD-RAM, DVD+RW,
DVD-RW, DVD-R, DVD+R. (cdrskin can do it on DVD+RW
and DVD-RW too, meanwhile.)


Bill Davidsen:
> > and -tao doesn't seem to work, for some reason cdrecord
> > thinks the TAO capability is missing.

Can i talk you into giving cdrskin a try ? 
Version 0.2.6 or later does TAO on CD.
(A drive really without CD TAO capability is worth to
be put on the pillory here. Like "Do Not Buy This One !")


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: input/output issue/bug in growisofs

[scdbackup]

Hi,

> I have had growisofs incorrectly find the size of the blank DVD+RW I put
> in my burner  (it found 2GB+ instead of the 4.7 which they have in
> reality).  A typical error message looks like this:
> :-( /dev/scd1: 2295104 blocks are free, 3589847 to be written!
> ...
> Mounted Media: 1Ah, DVD+RW
> Speed Descriptor#0:00/2295103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s

The blocks are of size 2 KiB (2048).
2295104 blocks is 4700372992 bytes. 4.7 GB (4482 MiB, 4.4 GiB)

My DVD+RW media report 
Speed Descriptor#0:00/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s


>  :-? the LUN appears to be stuck writing LBA=230540h,

It really fails at address 230540h which is 2295104 in decimal.
Quite as predicted by growisofs and dvd+rw-mediainfo.


Looks rather like your data is indeed too fat.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Probably incorrect profile name issued by cdrecord for 0014h

[scdbackup]

Hi Joerg,

i believe to have found an incorrectness in cdrtools-2.01.01a23

  $ cdrecord -v dev=0,0,0 -atip
  ...
  Current: DVD-RW sequential overwrite
  ...
  Profile: DVD-RW sequential overwrite (current)
  ...

Version 2.01.01a4 reports "Current: 0x0014".
In mmc5r03c.pdf this profile 0014h is labeled
  "DVD-RW Sequential recording"
(in contrast to 0013h "DVD-RW Restricted Overwrite")

So i believe the word "overwrite" is wrong with
profile 0014h and should be replaced by "recording".


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CD/DVD reliablity

[scdbackup]

Hi,

> The more general question is 
> Are CD / DVD media suitable for backup, at all? 
> On German TV there has been a warning recently that
> a CD (DVD) might get unrecoverable errors even with one year.

This touches two topics:

1) The question about backup suitability.

2) The question about our tv news shows and their technical
competence.


Yes. Both media are well suited for a reasonable backup
strategy. They are superior to the old medium-cost tape
technologies which i used in the past century (QIC tapes
DAT tapes, DEC TK). 
No comparison with the really low-cost tape devices of
that time.  They were just a nightmare.

For contemporary desktop technology CD and DVD face only
hard disk as competition. Anything else is too pricy.
Tape might be worth the money if you have to pay
operator hours according to german industry standards.
If you need affordable carry-away backups, then you will
hardly be able to avoid CD/DVD.

With any backup media you need verification after production
of the backup and precautions against subsequent media
deterioration.
CD and DVD are chemical media. So one has to avoid extreme
environmental storage conditions. On the other hand, magnetical
media are prone to electromagnetic influence.
If you can afford qualified storage of tape media then you
can afford qualified storage of CD/DVD too, i'm sure.


With backups of live systems it is important to replace them
regularly or alternatively to checkread those backups which
are stored for a longer time.
You have to fear two disasters: loss of your live data,
or loss of your backup. One of them you can afford. The
backup strategy has to ensure that you take notice of the
first disaster before the second one can happen. 
Having more than one backup on shelf increases your chance
to survive.

With archiving of outhoused data you cannot afford a disaster.
So you need means to early recognize deterioration and enough
redundancy in your archive to refresh the deteriorating data.
My proposal for this problem is to have several identical
copies ot the backup volumes, to permutate some of them in
order to expose different blocks to the same systematic errors,
and to have a mesh of block checksums to identify damaged
blocks.
Some archive formats like RAR have more sophisticated
solutions for the same problem.

However, one has to checkread the backups regularly and
take action if they go bad.


Practical experience:

My oldest CD backup under observation is of february 2003,
i.e nearly four years old. 62 CD-RW, some 2x some 4x.
They still all verify with their MD5 checksums.

My oldest DVD backup is of june 2004, 2.5 years now.
14 DVD+RW. All still verifying with reasonable reading
times.

Failure i experience with freshly burned media.

About 10% of my CD-RW which stored data for several months
fail to take the next burn properly. Most of them can be
revived by a second attempt - but some are unreliable
forever.
DVD+RW seem to stand long sleeping times better.


Now for german television:

A museum person who complains about audio CDs from the
1980s going bad. How's the state of his vinyl LPs from
that time ? Those which have been tortured by a diamond
needle ?
(Next question is wether the company which checked the CD
collection isn't by chance offering expensive rescue
services ? No ?)

A professor telling that one should not use CD for storing
holiday photos. Asked what to do if one wants to store
them somehow anyway - he advises to use 2 (two) CDs.

The news anchor then frightens the viewers (i.e MS-Windows
users) that all their data are at stake. Now. Yesterday.
All doomed.

Cut. (Good so.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Oddness piping mkisofs into recent cdrecord versions

[scdbackup]

Hi,

Bill Davidsen wrote:
> When I try to pipe an ISO into the cdrecord program, it complains that 
> it needs tsize= option to do the burn.

Is it possible you have trouble with this change
as of version cdrtools-2.01.01a20 ?

AN-2.01.01a20:
"Cdrecod now default to the write mode "-sao" in case that no write mode
has been specified. Cdrecord -multi continues to default to -tao.
If your drive does not support -sao, or if cdrecord does not support -sao
for your drive, you should now call cdrecod -tao."


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: About cdrecord -atip and -minfo

[scdbackup]

Hi,

me:
> >   Media-Current: CD-RW
> >   ...
> >   Media-Msinfo: 77434,87416
Bill Davidsen:
> is there any benefit to adding "Media-" to every line?

I asked myself the same. But i decided to stay with
that proposal because it allows to put it into a
larger frame of info messages about various topics.
One could want to report info about the drive or its
usage status.

Redundancy is not in vain, after all. It confirms
that you got the right line in your hands.
"Current:" for example, is a bit ambivalent and
would need an extension like "Current-Media:" or
"Current-Profile:" anyway.

So if we need lengthy names for the sake of 
uniqueness why not start a clean name space
layout ?
It won't become a tapeworm language like .xmi .

After all, it is only an illustration of what
i would experience as a helpful media info command.
A soup cooked from mail headers, /proc filesystem,
and what i saw of current cdrecord -minfo and -atip.

Important for me would only be that it is unambigous
and does not demand too much of state info in the
program which consumes the messages.
That's why i propose to tag each line of output.
So it is friendly to grep, sed and awk.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

About cdrecord -atip and -minfo

[scdbackup]

Hi,

me:
> >  not fixely standardized output of cdrecord -atip.
> > My backup tool is [was] grep'ing for "^  Is erasable".
Joerg:
> Maybe, I should go back to the old string at least for the -atip
> code as e.g. non-MMC drives stilll use the old string.

This seems to be a good idea.

As your long time user and frontened programmer i would
appreciate if the traditional ways of reporting media info
stay available and compatible. 
As your imitator i learned that other frontends do
interpret those messages and try to act accordingly.


> This is what -minfo currently prints for an appendable
> multi-border DVD+R:

I understand -minfo shall become a new general source of
media info.

The current man-page entry for "-minfo" is still a bit
sparse. So i assume the format is not fixely determined
yet. It would need to be open for future media, anyway.

Maybe you should strive for something like the e-mail
headers: Some of them are standardized by RFCs, some are
plain freestyle of mail tools. Heavy evolution, total mess
- but i can still pick from them the information i need.

For CD media, that could be something like :

  Media-Current: CD-RW
  Media-Profile: 000Ah CD-RW
  Media-Profile: 0008h CD-ROM
  Media-Write-Status: is written
  Media-Close-Status: is appendable
  Media-Reuse: is erasable
  Media-Speed-Max: 10
  Media-Speed-Min: 4
  Media-Content-Layout: Session Track TypeStart  End Size
  Media-Content-Track:1 1 data05525355254
  ...
  Media-Content-Track:5 5 data7743480515 3082
  Media-Msinfo: 77434,87416

The most important headers and their meaning should be described
in man cdrecord. Frontend programmers will love it.


Have a nice day :)

Thomas
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-reply:<[EMAIL PROTECTED]>

[scdbackup]

Hi Joerg,

cdrtools-2.01.01a22 on SuSE 9.0 :
- compiles out of the box (thanks a lot)
- does not show new 1000+ busses (as intended)
- works with my backup tool
  (at least on documented features)

cdrtools-2.01.01a22 on SuSE 9.3 :
- compiles out of the box (as did before)
- shows new 1000+ busses
- works with my backup tool 
  (at least on documented features)

-

One problem remains which is due to the not
fixely standardized output of cdrecord -atip.
My backup tool is grep'ing for "^  Is erasable".
That output line has changed recently to match
"^Disk Is erasable".

It was no problem for me to include the necessary
test in scdbackup. Old installations which get newest
cdrecord will need a new scdbackup, too. That's life.

But: will this text layout persist ?

  ATIP info from disk:
Indicated writing power: 3
Reference speed: 6
  Disk Is not unrestricted
  Disk Is erasable
Disk sub type: High speed Rewritable (CAV) media (1)
...
Is it intentional that those two lines are not indented
and that "Is" starts with a capital letter ?

The reason for scdbackup's interest in -atip output
is the wish to distinguish CD-R from CD-RW.
The more specific line which announces the current
profile
  Current: CD-RW
is not available with cdrecord-2.0, is not fully mature
in cdrecord-2.01 and also depends on option -v which
scdbackup users may disable.
So i would prefer to stay with "Is erasable" for general
compatibility. But with very specific grep expressions,
not just with "[Ii]s erasable" somewhere in some line. 

Can you give me an outlook wether the line will stay that
way or wether you plan to beautify it within the next few
revisions ?

-

Strange observation on SuSE 9.0 with LG GSA-4082B drive
but not with NEC ND-4570A.
After cdrecord blanked a CD-RW it reports on the
following burn:
  Capacity  Blklen/Sparesz.  Type
 0 2048  No Media Present or Unknown Capacity
The burn went well, nevertheless.

NEC on SuSE 9.0 and LITE-ON LTR-48125S on SuSE 9.3 with 4x media
report:
  Capacity  Blklen/Sparesz.  Type
276161 2048  Unformated or Blank Media
276161   32  Reserved (0)
2587200  Reserved (0)
12x media report is similar with higher Capacity.

-


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

Bill Davidsen wrote:
> What I was looking for is the setgid bit on a directory in
> /home/thomas/usr/bin

Well, there isn't. At least i could not spot.

> Copied with cp -p of course? To preserve ownership and permissions?

No. I toggled as root 

  mkdir /home/thomas/usr
  mkdir /home/thomas/usr/bin
  cp /usr/bin/cdrecord-2.01.01a21-hz100 /home/thomas/usr/bin

Everything else is provided by the quite fresh and
virgin SuSE 9.3 installation. ( / is hda1, /home is hda3.)

I will have to check wether the superuser got some
"helpful" alias on cp. That could indeed explain half
of the weirdness.

But not why a binary is reported by ls -l as owned by root
but with chmod u+s executes as thomas. That remains out of reason.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

> Bill Davidsen wrote:
> Does "ls -ld" show the same thing on both directories?
> No setuid on the directory itself, or anything like that?

I am firing up the old machine. (667 MHz and
needs a few minutes of pre-warming before boot)
Beep (is a good sign). Green SuSE jungle. 
I hate Firlefanz at startup.

  # alias ls=ls
  # ls -ld /usr/bin
  drwxr-xr-x  2 root root 32768 2006-11-30 12:23 /usr/bin
  # ls -ld /home/thomas/usr/bin
  drwxr-xr-x  2 root root 4096 2006-11-30 11:55 /home/thomas/usr/bin

Hm ... something is weird with the cp command.
The cdrecord binary in /home/thomas/usr/bin is a copy of
the one in /usr/bin. Copy made by the superuser.
The original is shown as owner=root, group=root.
The copy is user=root but group=users !

This is the nightmare of an admin.


> Nothing different with lsattr?
  
  # lsattr /usr/bin/cdrecord-2.01.01a21-hz100 \
  >  /home/thomas/usr/bin/cdrecord-2.01.01a21-hz100
  - /usr/bin/cdrecord-2.01.01a21-hz100
  - /home/thomas/usr/bin/cdrecord-2.01.01a21-hz100

  # getfattr /usr/bin/cdrecord-2.01.01a21-hz100 \
  >  /home/thomas/usr/bin/cdrecord-2.01.01a21-hz100

  # getfacl /usr/bin/cdrecord-2.01.01a21-hz100 \
  >  /home/thomas/usr/bin/cdrecord-2.01.01a21-hz100
  getfacl: Removing leading '/' from absolute path names
  # file: usr/bin/cdrecord-2.01.01a21-hz100
  # owner: root
  # group: users
  user::rwx
  group::r-x
  other::r-x

  # file: home/thomas/usr/bin/cdrecord-2.01.01a21-hz100
  # owner: root
  # group: root
  user::rwx
  group::r-x
  other::r-x

No s-bits listed. On both. Oh my ...

I will further explore ownership and group changes on
copying by the superuser. For this evening i am fed
up with weirdness and buzzing disks.

I shall celebrate that this is not a production system.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

> If you (thomas) have been able to chmod u+s on a file owned by root,
> then something looks broken.

The procedure is:
- "thomas" compiles cdrtools
- "root" copies ./cdrecord/OBJ/athlon-linux-cc/cdrecord to /usr/bin
It shows up as owned by root, group is root. (But somehow isn't.)
- "root" executes chmod u+s
Now it fails as effective user "thomas".
- "root" chowns it to root
Now it works as effective user "root".

But only on one partition. There is another ext3 partition
with exactly the same mount options. No problems on that.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

update and probably final report about the setuid problem on
SuSE 9.3 :

Joerg was right: with setuid bit the program is not
running as "root" but geteuid() returns the UID of
the previous owner of the file "thomas".

The problem seems bound to a single ext3 partition and
even there it is not easy to reproduce.
Any of the following actions make it vanish:
- copy binary to different partition and execute there.
- copy binary to different partition, copy back
  and execute at its old storage location.
- apply  chown root  once again after chmod u+s
  (older chown implementations cleared setuid
   bit and thus i first chown and then chmod).

My findings give enough room for explanations why we
never heard of such problems when SuSE 9.3 was freshly
introduced.

Unclear remains why the system's "cdrecord" binary
joined the club of refuseniks. I changed its name
and i applied chmod u+s, but it was never owned by
user "thomas". (Pity i cannot make it tell its
geteuid()).


State on my kernel 2.4 (SuSE 9.0) system:
  cdrecord-2.01.01a21  works with the patch about
  LINUX_VERSION_CODE <= 0x020600

State on my kernel 2.6 (SuSE 9.3) system:
  cdrecord-2.01.01a21  works unpatched

Sorry again for the confusion about SuSE 9.3.
It had nothing to do with cdrecord itself.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

> > Permission denied. Cannot open '/dev/sg1'. Cannot open SCSI driver.
> cdrecord is not installed suid root or you are not calling as root.

I swear. It only makes trouble after chmod u+s .

  -rwsr-xr-x  1 root root 391843 2006-11-29 20:45 
  /usr/bin/cdrecord-2.01.01a21-hz100

In that state it makes trouble with all users.
After chmod u-s it is usable for user root:

  -rwxr-xr-x  1 root root 391843 2006-11-29 20:45
  /usr/bin/cdrecord-2.01.01a21-hz100

Same with the system's The-author-of-cdrecord-should-
not-be-bothered "cdrecord" binary.


> Do you believe that this is a Suse 9.3 specific bug
> in the Linux kernel?

I wouldn't blame it on a particular component or layer,
but yes: it is weird enough to be a very specific bug.
I don't believe it is intentional ... and i am quite
sure to have heard of SuSE 9.3 systems where cdrecord did
work for normal users (i.e. setuid root).

My hardware is elderly and a bit flaky on startup.
I did set up the system for test purposes on my previous
computer. Everything else about CDs seems to work fine,
though. For a hardware problem, it seems much too specific.
It seems not to be bound to recent cdrecord development.
The system includes a Cdrecord-Clone 2.01 (i686-suse-linux) 
Copyright (C) 1995-2004 Joerg Schilling with the same
problem:
  /usr/bin/cdrecord-suse-9.3: No such file or directory.
  Cannot open SCSI driver.

Let's count it as single individual problem unless somebody
else shows up with the same. I'm ready to do tests on request.

There must be some software trigger. Is there something
wrong with the mount options ?
  /dev/hda1 on / type ext3 (rw,acl,user_xattr)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

> Does a suid root binary work in case that there is
> #if LINUX_VERSION_CODE <= 0x020600

Nope. I test with a simple cdrecord -scanbus :

The binary from 9.0 stumbles over /dev/sg1 :

  /usr/bin/cdrecord-2.01.01a21-hz100-suse-9.0:
  Permission denied. Cannot open '/dev/sg1'. Cannot open SCSI driver.

The binary from 9.3 feels not entitled to react on <= 0x020600:
  EXPERIMENTAL: LINUX_VERSION_CODE = 2060B
  /usr/bin/cdrecord-2.01.01a21-hz100:
  Permission denied. Cannot open '/dev/hda'. Cannot open SCSI driver.

With #if LINUX_VERSION_CODE <= 0x02060B it is the same
as with the binary from SuSE 9.0:
  EXPERIMENTAL: LINUX_VERSION_CODE = 2060B
  Linux sg driver version: 3.5.32
  /usr/bin/cdrecord-2.01.01a21-hz100: 
  Permission denied. Cannot open '/dev/sg1'. Cannot open SCSI driver.


There is no hardware attached to /dev/sg1.
The old CD-ROM is /dev/sg0, the burners are /dev/hd[cd].
The disks are hd[ab]. No SCSI disk.

CD devices recognized by libburn:
  0  dev='/dev/sg0'  rwrwrw :  'TEAC'  'CD-ROM CD-532S'
  1  dev='/dev/hdc'  rwrwrw :  'HL-DT-ST'  'DVD-ROM GDR8162B'
  2  dev='/dev/hdd'  rwrwrw :  'LITE-ON'  'LTR-48125S'


> There are reports that this hald sometimes interrupts the burn process.

My trouble currently is that cdrecord and cdrskin do not
lock against each other on SuSE 9.3. 

On the kernel 2.4 system cdrecord aborts on collision:
  cdrecord: Device or resource busy. 
  Cannot open '/dev/sg0'. Cannot open SCSI driver.
whereas cdrskin intentionally ignores a busy drive,
states it wasn't available and then it aborts.
Whatever, they both do not spoil each others ongoing work.

cdrskin opens O_EXCL|O_NONBLOCK and this still works
on cdrskin-to-cdrskin collisions on the SuSE 9.3 system.
But with cdrecord it is out of touch.


Have a nice day :)

Thomas
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

on SuSE 9.3 the problem with 
  /usr/bin/cdrecord-2.01.01a21-hz100: Permission denied. Cannot open 
'/dev/hda'. Cannot open SCSI driver.
is not bound to the binary from SuSE 9.0 but to the
setuid bit:

The locally compiled version does not work any more
as soon as it is treated with chmod u+s by the superuser.
After that it does not work for a su superuser either.

The only visible difference between the binaries from
SuSE 9.0 and 9.3 is that the 9.0 binary omits the ATA busses
unless dev=ATA is given with -scanbus.
(Because of the #if LINUX_VERSION_CODE <= 0x020600 ,
i assume.)

Sorry for any confusion.


To my great surprise all burn programs work despite there
is a hald which automounts any ISO-CD inserted into any of
the drives.
The first auto-thingie that i have seen which is not a pain
in the ass on the first attempt.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

> >   http://scdbackup.sourceforge.net/cdrskin-0.2.6.pl01.tar.gz
> It still does not have a working "configure".

If that happens on Linux with a 2.4 or 2.6 kernel
then this is a defeat for our project (and for
autotools, possibly).

I would appreciate a complete log of the failed
configure run. Like from:

  ./configure 2>&1 | tee -i /tmp/cdrskin_configure_log

Helpful would be the output of your system's

  uname -a

plus the MD5 of the tarball which you unpacked.


> Well, Linux is not the world

Indeed it isn't. But it happens to be the operating system
of those whom i know and who do not use Microsoft Windows.

libburn's lowlevel SCSI adapter is prepared for porting now,
but we would need system experts, test systems and testers.
(A FreeBSD port sketch for CAM exists. The task for the system
expert would be to introduce us to the equivalent of Linux sg
or FreeBSD CAM.)


> It looks like you are misunderstanding the libscg interface.
> Have a look at the syntax definitions in the source files

I will make use of your invitation. But for now i did
not try to understand your sources but only studied the
use cases of cdrecord and its recognizable behavior in
particular situations.

>From the user point of view, cdrecord's approach towards
drives was much superior to libburn's (see ill DVD-ROM).
libburn's builtin ability to address a default drive
did not outweight the disadvantages and risks of a mandatory
full bus scan.
This ability is convenient and cdrskin makes use of it
- but only if there is no drive given explicitely.


> > ill DVD-ROM which stalled libburn's
> > also stalled  cdrecord dev=ATA -scanbus on a Linux 2.6 kernel.
> This looks like a Linux bug.

Stalling is not a nice behavior on open(), indeed.

But see how elegantly cdrecord avoided any trouble
by just not touching the ill drive. 
Ok, dev=ATA -scanbus was broken. But no reasonable user
would run that command on a system with ide-scsi burners.
And even if a normal -scanbus would have included a
dev=ATA scan and would thus have failed: one still
could have used both drives dev=0,0,0 and dev=0,1,0.

The new approach makes cdrecord more prone to external
disturbance. Especially with those use cases where no
option -scanbus is present.


> "make relink"

That one is new to me.

> read the documentation

I already got square eyes from acroreading SPC/SBC/MMC
specs in various draft versions ...
Allow me to stay with try-and-error as long as i succeed
in less than three attempts :))


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

> I don't care about libburn, it is so broken that it does not even complete
> it's "configure" run:
> checking for a BSD-compatible install... /opt/sfw/bin/ginstall -c
> ./configure: line 19396: syntax error near unexpected token `in'
> ./configure: line 19396: `for ac_header in'

That looks much like an icculus.org/burn libburn-0.2 tarball
or CVS version prior to about march 2006. (Newer bash versions
accept an empty "for" list. I noticed that problem only on
a SuSE 7.2 system. Meanwhile our ./configure is fat but legal.) 

The stable current version is available as
  http://libburn-download.pykix.org/releases/libburn-0.2.6.1.tar.gz
resp. with identical code base as
  http://scdbackup.sourceforge.net/cdrskin-0.2.6.pl01.tar.gz

It seems to compile on all the contemporary Linux distros.
I would appreciate any bug reports.


> > So - if you want advise - disable that new auto-scan feature
> > unless an explicit drive address is missing.
> As this is not doable before you did scan, it would need toi
> stay similar to how it is.

But you do know wether there is a dev= option before you
start with the bus scan, don't you ? In that case it seems
wise to me to omit that total scan and to only touch the desired
drive(s). (I mean, i learned this from *you*. It is much better
a strategy than the one of old libburn. You should not give
up anything of the stability of cdrecord by scanning without
need.)

A few months ago i had an ill DVD-ROM which stalled libburn's
bus scan as long as DMA was on. In that state it also stalled 
cdrecord dev=ATA -scanbus on a Linux 2.6 kernel.
Ill hardware, no doubt. Nevertheless it made all healthy drives
unusable - for libburn. cdrecord without dev=ATA had no problem.
I made libburn have no problems with that too.


> #ifdef  USER_HZ 
>tmo *= USER_HZ; 
>if (tmo) 
>tmo += USER_HZ/2; 
>#else 
>tmo *= HZ; 
>if (tmo) 
>tmo += HZ/2; 
>#endif 

The compiler still complains about HZ.
I guess the file necessary for USER_HZ is not included.

I flatly inserted the usual header files from some of my
own programs into libscg/scsi-linux-sg.c , but no USER_HZ
did show up.

fgrep finds asm/param.h only in files which are as obscure:
/usr/include/linux/jiffies.h:#include   /* for HZ */
/usr/include/linux/param.h:#include 
/usr/include/linux/sched.h:#include /* for HZ */
/usr/include/linux/time.h:#include 
/usr/include/linux/timex.h:#include 

For me it would be easier to just copy the line
  #define USER_HZ   100
into libscg/scsi-linux-sg.c .


> > The drive /dev/hgd did never interact with cdrecord.
> Then this 
> #if LINUX_VERSION_CODE <= 0x020600 
> if (use_ata) 
> #endif 
> for (i = 0; i <= 25; i++) { 
> js_snprintf(devname, sizeof (devname), "/dev/hd%c", i+'a'); 
> should work

After make clean ; make : Yes.
(No new cdrecord binary emerges without make clean)

My two burners are reachable again.
The DVD-ROM at /dev/hdg shows the same error
messages as with any cdrecord-2.01.01 version.


from libscg/scsi-linux-sg.c :
> The CD/DVD writer case may
> * look silly but there may be users that did boot from a SCSI hdd
> * and connected 4 CD/DVD writers to both IDE cables in the PC.

It is not silly at all with modern mainboards which
often have the hard disk at SATA. With those boards
ATA:0,0,0 is quite a natural address for the only
CD/DVD drive.
(That confused me at first when i tried to find out
how you are deriving the ATA:Bus,Target,Lun addresses.
Google is full of "ATA:0,0,0" examples.
My emerging theory said "/dev/hda" and my experience said
"nonsense". Then a workmate bought a new computer and
really ATA:0,0,0 is /dev/hda.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

> I did never see any problems from a missing HZ definition.
> It looks like a bug on this distribution

We discussed it in July 2004. Yes it is a distro bug
which i workaround each time i compile your source
releases. SuSE 9.0 seems to suffer from a mix of 100
and 1000 Hz. Probably the missing of a HZ macro is
meant to express and emphasize this interesting state.

> 1)  is USER_HZ available on that system?
> 2)  what value is in USER_HZ?

/usr/include/asm/param.h:# define USER_HZ   100

> 3)  Are there system where USER_HZ is available but the SCSI code
> uses HZ as base for timeouts?
> 4)  Are there systems where HZ is != 100 but the SCSI code uses
>HZ as base for timeouts?

Don't know. I just settled to HZ 100 and it always worked
flawless. This applies to my individual system only, of course.

We once filed the problem as a temprorary flaw of the SuSE distro.
They did correct it meanwhile :))


> are you able to access the non-ide-scsi drive with older cdrecord versions?

No. In a positive sense.
The drive /dev/hgd did never interact with cdrecord.

But it is quite a while since i last tested wether 
dev=ATA -scanbus yields results on my system.

  $ cdrecord dev=ATA -scanbus
  Cdrecord-ProDVD-Clone 2.01.01a12 ...
  ...
  cdrecord: Read-only file system. Cannot open '/dev/hdg'. Cannot open SCSI 
driver.
 
Same with
  cdrecord-2.01.01a4
  cdrecord-prodvd-2.01.01b03-i686-pc-linux-gnu
  cdrecord.2.01a33
Older versions in my collection obviously do not recognize dev=ATA.

I am not aware to have seen the "Cannot open" error message
when i explored dev=ATA about 1 or 2 years ago. I do remember
that dev=ATA -scanbus did not yield a bus list of drive items
as successful bus scans do.
Since then i added a Promise Ultra 133 TX2 IDE controller and
the drive moved from hdd to hdg. Unclear wether this made any
difference.
(It does, of course, make much difference when using drives
simultaneously. hdc+hdd did suck. hdc+hde+hdg works great.)

I do remember that a bus scan test with the same computer 
under a Slackware kernel 2.6 based rescue system shows the
drive as /dev/hdc "ATA:1,0,0". (The controllers swap places
depending on what Linux i boot. There is a bootloader
option ide=reverse by wich i might try to influence that.)


> Are you able to sens SCSI commands to this drive without using
>   cdrecord dev=ATAPI:...

On SuSE 9.0 i cannot get cdrecord-2.01.01a21 to anything but
eventually printing help texts. Any drive operation fails
with the complaint about /dev/hdg. (Wether i use the known 
addresses 0,0,0 and 0,1,0 for the ide-scsi burners or "/dev/hdg"
or guessed ATA:3,0,0 .)

Older cdrecords work well with the burners but refuse on
dev=/dev/hdg or any dev=ATA:... with the known hdg complaint.

The other way known to me how to send SCSI commands is
via libburn resp. its ioctl(SG_IO), which needs a O_RDWR 
filedescriptor, which i cannot get because of the errno 30
with open().
So: no SCSI commands sendable for now.


> returning EROFS is a POSIX violation, see:

I see. It would be legal if /dev was on a read-only
file system but not if /dev/hdg is unable to host a
read-write filesystem.

Please consider just to ignore drives which return that
error and not to abort the whole cdrecord run which addresses
other drives resp. tries to scan the bus.  


> > [cdrecord built on SuSE 9.0 fails on SuSE 9.3]
> > After all, the binary built on the local system did work.
> It is even stranger that a locally build binary behaves different.

For a few years we were free of those binary compatibility
problems - at least within SuSE versions. Sigh.


> It would be possible to disable /dev/hd* scanning (by default)
> for pre-2.6 systems. 

I supported the recent libburn fork because there was a
mandatory bus scan before any drive usage which caused various
trouble. The decisive patch which icculus.org/burn did not
accept was about restricting the bus scan to one single
predicted drive address.
This earned me developership with an own burn library. 
Sigh ... chuckle.

So - if you want advise - disable that new auto-scan feature
unless an explicit drive address is missing. Also, avoid to
get hampered by problematic drives which are not given 
explicitely by dev= . I had some weeks of work to achieve
the same with cdrskin. It seems to be very handy that way.


Have a nice day :)

Thomas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

> > '/dev/hda'. Cannot open SCSI driver.
> This looks to be impossible: If you run cdrecord with the apropriate rights 
> (root) you should be able to open /dev/hda.

I was root. Via su login, not via setuid.

Blame it on SuSE library configurations.
After all, the binary built on the local system did work.


> dev=ATAPI != dev=ATA

Evidential :))


Actually what bothers me is the refusal on my 2.4 kernel
with the /dev/hdg DVD-ROM. I found no trick to get it
over that "Read-only file system. Cannot open '/dev/hdg'."
Both burners stay unreachable for cdrecord-2.01.01a21 .


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

>  1000,1,0 11) 'MATSHITA' 'UJ-840D ' '1.03' Removable CD-ROM

Just for the curiosity of an emulator:
Is this /dev/hdb ? (resp. dev=ATAPI:0,1,0 ?)


Update on 2.01.01a21 testing:

This time with a SuSE 9.3 system. Kernel 2.6.11.4. No ide-scsi.

The binary from the SuSE 9.0 system goes on strike because of
/dev/hda which is a hard disk. Run as superuser it reports:
  /usr/bin/cdrecord-2.01.01a21-hz100: Permission denied. Cannot open 
'/dev/hda'. Cannot open SCSI driver.


The same source (*) cdrtools-2.01.01a21.tar.gz compiled on this
newer system works better, though. 
cdrecord -scanbus (without any dev=) detects all three devices:

Classical SCSI controller attached antique CD-ROM:
  0,3,0 3) 'TEAC' 'CD-ROM CD-532S  ' '1.0A' Removable CD-ROM
/dev/hdc DVD-ROM: 
  1001,0,0 100100) 'HL-DT-ST' 'DVD-ROM GDR8162B' '0015' Removable CD-ROM
/dev/hdd CD-RW burner:
  1001,1,0 100101) 'LITE-ON ' 'LTR-48125S  ' '1S05' Removable CD-ROM

(*) a difference might be that the #define HZ 100 does not
get into effect on the newer SuSE system.


Strange observation: dev=ATAPI -scanbus shows single digit bus numbers
with the IDE drives together with the real SCSI controller's bus.

  $ cdrecord dev=ATAPI -scanbus
  Cdrecord-ProDVD-Clone 2.01.01a21 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling
  ...
  scsibus0:
...
0,3,0 3) 'TEAC' 'CD-ROM CD-532S  ' '1.0A' Removable CD-ROM
...
  scsibus1:
1,0,0   100) 'HL-DT-ST' 'DVD-ROM GDR8162B' '0015' Removable CD-ROM
1,1,0   101) 'LITE-ON ' 'LTR-48125S  ' '1S05' Removable CD-ROM

What would happen if there was a CD device at /dev/hdb ?
Would it be reported as 0,1,0 ?

cdrecord dev=ATAPI:1,1,0 -atip  needs about 30 seconds before the
tray gets loaded and another minute to obtain the info.
dev=ATAPI:1,0,0 -eject needs more than one minute.

In AN-2.01.01a20 i read:
  "- Warn Linux users to prefer dev=ATAPI: over dev=ATA:"

But cdrecord-2.01.01a21 issues this text:
  "Warning: dev=ATA: is preferred over dev=ATAPI:."


With dev=ATA i get the IDE part of the -scanbus list:

  $ cdrecord dev=ATA -scanbus
  ...
  scsibus1001:
1001,0,0 100100) 'HL-DT-ST' 'DVD-ROM GDR8162B' '0015' Removable CD-ROM
1001,1,0 100101) 'LITE-ON ' 'LTR-48125S  ' '1S05' Removable CD-ROM

On these addresses, -atip and -eject do work with usual speed.
(dev=1001,1,0 or dev=ATA:1001,1,0 seems to make no difference.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present

[scdbackup]

Hi,

regrettably cdrecord-2.01.01a21 seems to be unusable on my
Linux 2.4 system which has 2 burners under ide-scsi and
1 DVD-ROM not under ide-scsi.

I downloaded 
  ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a21.tar.gz
made my usual "#define HZ 100" in libscg/scsi-linux-sg.c, compiled,
and ran

  $ cdrecord -scanbus
  Cdrecord-ProDVD-Clone 2.01.01a21 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling
  cdrecord: Read-only file system. Cannot open '/dev/hdg'. Cannot open SCSI 
driver.
  cdrecord: For possible targets try 'cdrecord -scanbus'.
  cdrecord: For possible transport specifiers try 'cdrecord dev=help'.


"Read-only" obviously doesn't mean file access permissions:
  brw-rw-rw-1 root disk  34,   0 Sep 23  2003 /dev/hdg

It seems to be a true regression in relation to my system:

  $ /usr/bin/cdrecord-2.01.01a12-hz100 -scanbus
  Cdrecord-ProDVD-Clone 2.01.01a12 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling
  Linux sg driver version: 3.1.25
  Using libscg version 'schily-0.8'.
  scsibus0:
0,0,0 0) '_NEC' 'DVD_RW ND-4570A ' '1.02' Removable CD-ROM
0,1,0 1) 'HL-DT-ST' 'DVDRAM GSA-4082B' 'A201' Removable CD-ROM

With the newest version it is not even possible to address
a single known drive:

  $ cdrecord dev=0,0,0 -atip
  Cdrecord-ProDVD-Clone 2.01.01a21 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling
  ... same complaint about /dev/hdg and refusal to work ...


The situation on my system is as follows:
  Linux 2.4.21 ( SuSE 9.0)
  /dev/hdc -> /dev/sg0 , /dev/sr0, dev=0,0,0
  /dev/hde -> /dev/sg1 , /dev/sr1, dev=0,1,0
  /dev/hdgis a DVD-ROM without ide-scsi emulation

(libburn encounters this /dev/hdg too. It gets ignored
because open(2) returns error 30 "Read-only file system".)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Philips DVD8801 or other Drive work wrong

[scdbackup]

Hi,

>  crash with ide-scsi hda [...] ack=08h [...] ACK=07h [...]
> Which drive can I use to work correctly 

Well, the error description is a bit sparse.
The fact that two different drives fail is not
very encouraging in respect to further drives.
Did you really run the Liteons successfully with
the same cable at the same IDE controller ?

On a SuSE 2.4.21 kernel with ide-scsi i use
 LG GSA-4082B (2 years old)
 NEC ND-4570A (1 month old)
The LG fails with most DVD-RW brands but elsewise
everything works well with growisofs.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: a question on pipes and growisofs

[scdbackup]

Hi,

I wrote:
> >   star -c -acl -link-dirs level=0 . | gzip | growisofs ...
Joerg Schilling wrote:
> For backups, I recommend to use star's "dump" format (created if you 
> add -dump to the command line).

We discussed this in August 2005 on star-users :
http://lists.berlios.de/pipermail/star-users/2005-August/000417.html

Me:
> > Do you mean with "make backups" that i should always
> > use option -dump (or "level=0") ?
You:
> If you like a complete backup, is is the best to use level=0.
> In this case, star forces you to backup the complete filesystem
> and archives even more data about the FS.

Reading  man star-1.5a64/star/star.1  (i did not update
since a year, i confess) i get the impression that the features
of level=0 are a superset of -dump.

I would have to change my star adapter if -dump was really
superior over level=0 for the special purpose of backing up
a sleeping system partition - in order to get true disaster
recovery - but more portable than a flat device copy.
(This recovery indeed worked in a brute test in september 2005.
The restored Linux was fully operational afterwards.)


Have a nice day :)

Thomas




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: a question on pipes and growisofs

[scdbackup]

Hi,

> So, I want to be able to "tar -cf file.tar /mnt/sda4" and "growisofs -Z
> /dev/dvd/ -udf file.tar". I guess that to be able to do it, I should use
> a pipe, but I don't know how to do it.

My two cents.

Number 1:

  tar cf - /mnt/sda4 | growisofs -Z /dev/dvd=/dev/fd/0

will write the tar archive rawly to DVD.
To be read from unmounted DVD with
  tar tvf /dev/dvd

Better archivers for this purpose are afio and Joerg's star.
They recognize the end of an archive and thus do not have problems
with the fuzzy end of a DVD.

  find . | afio -oZ - | growisofs ...

resp.

  star -c -acl -link-dirs level=0 . | gzip | growisofs ...

If you need a mountable filesystem with an archive file in it:
mkisofs -stream-media-size can put a stream into a dingle file
ISO9660 file system. I never tried this myself.
One would have to put the mkisofs command into the pipe between
archiver command and growisofs.


Number 2:

My project
  http://scdbackup.sourceforge.net/main_eng.html
provides multi volume backup in formats ISO-9660, afio or star.
The appropriate commands would be

  sdvdbackup_afio .

resp. in star format

  export SDVDBACKUP_AFIO="$(scdbackup -where scripts)/star_as_afio_wrapper -acl"
  sdvdbackup_afio .


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mkisofs memory hungry?

[scdbackup]

Hi,

> > I got a subtree of 2 million empty files where mkisofs
> > exceeds 2 GB of memory consumption. I never found out
> > wether it would finally end or crash.
> Why? Did you stop it?

I began to fear about the health of my consumer disk.
Hours of extreme disk rattling due to the fight of
stat() and swap (1 GB RAM, 2 GB swap partition).
I was not curious enough to wait for the outcome.

The usual archivers produce 500 MB of uncompressed
result from that subtree within half an hour (slow
enough) and with not more than the usual memory footprint
of a few single MB.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mkisofs memory hungry?

[scdbackup]

Hi,

> DVD backup server. This machine has 96MB memory,

That machine must be several years older than the
DVD burner.


> I thought mkisofs is somewhat pipeline process, files comes in, iso
> images goes out. I thought the memory needed is not directly related to
> the amount of data to make ISO image,

My experience is that memory consumption of mkisofs 
depends mainly on the number of files. 

A consumption of 50 to 100 MB for a 4 GB ISO image is
not unusual. That's single percent of payload.
Since you got many small files, the ratio might be higher.

I got a subtree of 2 million empty files where mkisofs
exceeds 2 GB of memory consumption. I never found out
wether it would finally end or crash.


> Thanks for suggestions and ideas in advance.

You could abandon the concept to record all your files
directly in an ISO image and rather employ some archive
format.

You may burn archives from afio or star without an ISO
wrapper. Both programs are smart enough to unpack from
media which do not deliver a clean end-of-tape.
Like
   find . | afio -ovZ - | growisofs -Z /dev/hdc=/dev/fd/0
To be read from unmounted media like
   afio -ivZ  /dev/dvd

This is what i use for system backup in single user mode:
   star -c -xdev -acl -link-dirs level=0 -C /mnt . \
| gzip | growisofs -Z /dev/hdc=/dev/fd/0
To be read by
   gunzip http://www.serice.net/shunt/
which produces ISO images with a series of tar archives
on-the-fly. (Look for "flyisofs")


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

cdrecord -toc on blank CD-RW exits 0. Intentional ?

[scdbackup]

Hi Joerg,

is it intentional that cdrecord returns exit value 0
after  -toc  failed quite loudly on a blank CD-RW ?

If yes: i am curious about the particular reason.
The exit value on empty tray is 255.


  $ cdrecord -v dev=0,1,0 -toc  && echo "CDRECORD SUCCESS"
  Cdrecord-ProDVD-Clone 2.01.01a12 (i686-pc-linux-gnu) 
  Copyright (C) 1995-2006 Jörg Schilling
  ...
  Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
  cdrecord: Input/output error. read toc: scsi sendcmd: no error
  CDB:  43 00 00 00 00 00 00 00 04 00
  status: 0x2 (CHECK CONDITION)
  Sense Bytes: 70 00 05 00 00 00 00 10 43 00 00 90 24 00 00 C0
  Sense Key: 0x5 Illegal Request, Segment 0
  Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0
  Sense flags: Blk 0 (not valid) error refers to command part, bit ptr 0 (not 
valid) field ptr 0
  cmd finished after 0.002s timeout 40s
  cdrecord: Cannot read TOC header
  cdrecord: Cannot read TOC/PMA
  CDRECORD SUCCESS


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Request for cooperation with all burn backends

[scdbackup]

Hi,

Joerg Schilling:
>> Cooperative locking is needed in a way that allows and is based not on
>> device nodes but on real hardware targets.
Bill Davidsen:
> I'm less sure about cooperative locking, any method which fails if any one 
> program behaves badly is not scalable.

It seems to be a hard constraint in the burn community
that the locking mechanism has to allow free access to
the drive if the burn program deems its actions harmless.

Full responsibility has as precondition a sufficient
knowledge of the situation, nevertheless. So the burn
programs need at least some means to announce their 
disturbance-sensitive activities on a drive and to detect
such announcements before starting any activity which
assumes exclusive usage of the drive.


Bill:
> A perfect solution also must address locking of
> partitions vs. locking the entire device.

Partitions with burner programs ? 
How do partitions apply to us ?

> I have a little paper somewhere 

If possible i would be interested to read.

As said, i do not strive for a perfect solution
but for one that gives some hope and chance for
mutual good-will programming.

Main concerns currently:

- An unambigous mapping from drive addresses as known
  to the burn programs to the physical drives which we
  actually want to address.
  I consider to put the full load of this to a server
  process.

- A minimal footprint in the code of the burn programs
  so that everybody is willing to include the necessary
  software and to participate in the cooperation.
  This client code shall only provide a unique process id,
  transfer the known (reversely ambigous) address of the
  drive to the server and recieve the reply wether the
  (unambigous) drive could be exclusively reserved or not.


> I don't know that any solution which depends on every program 
> cooperating will be practical, and in fact automounters seem to ignore 
> the rest of the world.

The good willing programs and developers are the
ones whom i want to address here.

If we ever get a practical locking convention implemented
on the most important operating systems then the next step
might be a coordinated move of burn developers towards
automounter developers. It would spare both sides lots of
anger if we would not have our software fighting.


> I'm leaning toward Joerg's thought that locks on inodes referencing 
> physical devices should work at the device level to avoid aliasing issues.

This is the other hard constraint that emerged from the
discussion so far: device file locking is insufficient.
Even device driver locking is not what we need.
We need to cooperate on the drive. One drive - one lock.

Not so clear are:

- How much is it worth to us ? How much effort will each
  developer accept in order to participate ?

- What operating systems need to be covered by a first
  suite of locking servers and how complicated will it
  be to implement unique drive identification on each ?
  My ideas for Linux are not 100% fool proof but would
  work for the configurations known to me:
  /dev/hdX device driver or (emulated) SCSI devices.


> SysV message queue

msgget, msgsnd, ...
Indeed a candidate. Installed on my Linux.

Then there is mq_open, mq_send, ...
Labeled "POSIX". Not installed on my Linux.

I will consider to use this.
It has not the advantage of TCP/IP to detect the demise
of a lock holder by the end of the connection.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Request for cooperation with all burn backends

[scdbackup]

Hi,

Andy:
> > > int grab_sg (int blkfd)
me:
> > Seems to work well for me and my two drives sr0 and sr1.
Joerg:
> Forget about this "method". It is known not to work reliably on Linux
> and similar moethods will not work at all on other OS.

This is a kind of emergency patch for a particular
problem with (some ?) Linux kernels 2.4 .

I am very thankful to Andy that he addresses old
kernel 2.4 at all. His proposal will allow me to
detect growisofs runs on a drive and to stay off.

 
> The problem on Linux is device aliasing that results in many independent
> device nodes.

Yep. O_EXCL fails to provide the needed functionality
under many circumstances.
Above function will allow growisofs and libburn to
meet at the same Linux /dev/sgN and there locking
should work.
(Same works fine between cdrecord and libburn.)


> Cooperative locking is needed in a way that allows and is based
> not on device nodes but on real hardware targets.

I agree to this statement in general.
(Above sg grabbing is not a widely usable solution.)

My ideas are about a central dispatcher service which
arbitrates locking requests. It could encapsulate nearly
all OS dependency if we manage to find an OS independend
communications method and make it understand all
our permissible address formats (permissible on the
particlar OS).

If it can use a reliable OS provided locking mechanism:
Very good. It should do.
If not: it has to provide some own functionality for locking.

On Linux i would implement it via scsi address parameters
resp. major,minor device number pairs. Possibly configurable
to teach it about hardware coincidences of distinct
device drivers.


Andy:
> > > Have you seen resmgrd?
me:
> > I found this overview of 2006-09-29:
> >   http://forgeftp.novell.com//resmgr/web/README.html
Joerg:
> Last time, I did look at this software, it was full of conceptional bugs

I agree that it does not qualify as solution to our problem.
It offers locking, but in a way that i can top by my own
experiments or by an old NFS-wide locking tool from early
1990s which marks lock files with an expiration date.
(It is a bit fat, though.)


> > Next i will try to find out wether HAL would be of more
> > help.
> 
> HAL is known to be a non-cooperative program that interrupts
> CD/DVD writing.

If its concept allows the type of locking we need,
then one could try to negociate a less disturbing
operation with the HAL developers.

In our general usage scenario, HAL would only be one
implementation of a lock mechanism, if ever.
I still plan to evaluate wether it would roughly provide
the needed gestures. But i do not plan to depend on it.


> Sun is just working on a new vold implementation 
> for better GNOME support. Let us wait until this has been finished

Got an URL for me to learn about its suitability for
locking ?

On Solaris our arbiter could be a frontend to vold
if that provides the needed functionality. That would
bring us in sync with other vold locks.
In this case the aribter's only service would be to
provide the standardized communcations protocol
for the burn programs and a gateway to vold.


me:
> > I had a significant increase in DVD misburns as long as
> > libburn opened and inquired the drive for its bus scan.
Joerg: 
> Then you did something wrong.

That's well possible. I will try to find out, eventually.

But given my current lack of drive- and transport-level 
knowledge this may last a while. I am still suckling
on the previously existing libburn code in that aspect.
So i better try to stay off drives used by programs
which know better.


Andy:
> > [Once again] given that we're talking about Linux,
Joerg:
> If you are talking about Linux only, we should stop this discussion.

We got two levels of abstractions in this topic:

1) The particular 2.4 problem between growisofs and libburn.

2) The general problem that we are quite blind towards the
   activities of concurrent burn processes.

Number 1) is on a good way thanks to Andy.
(I'm just waiting for seeing how he integrates grab_sg()
into growisofs.)

Number 2) is still collecting divergent opinions and
might need some time until a proposal emerges which
fulfills the minimal needs without imposing too much
load on the developers.


> It would rather make sense to implement a 
> demonstrator on a OS that has a better design and then tell the Linux kernel 
> developers what to do.

I am still in favor of doing our own thing in user
space.
One would eventually use OS facilities of sufficient
quality for that, but also to have a generic
implementation concept which is "very portable".

The clients shall not see much diversity between
OSes. They will need to get a unique process id
and to perform the necessary communications with
the arbiter.

Communication transport candidates are plain files
and TCP/IP for now. The convention about the
file addresses resp. TCP/IP port might become
system dependent.


We should not dismiss the idea just because we
do not have a good solution yet. 

Re: Request for cooperation with all burn backends

[scdbackup]

Hi,

> int grab_sg (int blkfd)

Seems to work well for me and my two drives sr0 and sr1.

I threw out two of my three functions and made
try_to_lock_linux_sg() using grab_sg() instead.

The call in builtin_dd() has changed a bit:

if (i == 3 && fd >= 0)
try_to_lock_linux_sg(ioctl_device, fd);


I made a small change in grab_sg() in order to distinguish
a failed locking attempt from failure to get to that attempt.

#include 

int grab_sg (int blkfd)
{
  ...

if (sgfd>=0)
{ 
 ...
}
else if (errno == EBUSY)
sgfd = -2;

  ...
}

void try_to_lock_linux_sg(char *ioctl_device, int ioctl_dev_fd)
{
int fd_sg = -1;

if ( ( ( strncmp (ioctl_device, "/dev/sr", 7) == 0
&& isdigit(ioctl_device[7]) ) ||
   ( strncmp (ioctl_device, "/dev/scd", 8) == 0
&& isdigit(ioctl_device[8]) )
   ) )
fd_sg = grab_sg(ioctl_dev_fd);
if(fd_sg == -2)
fprintf (stderr,":-( unable to O_EXCL sg equivalent of %s: "
"Other burn program active on drive ?\n",
ioctl_device),
exit (FATAL_START(errno));
}

I will now use this variation of growisofs 7.0 for my daily
backups. It will last a few days until i get opportunity
to test it on kernel 2.6 and /dev/hdX.
If my code is as intended then this should not even call
grab_sg(), and of course never abort.

Give me a note as soon as you decided for a final implementation
and i will test as good as i can.


Have a nice day :)

Thomas


PS: About -Z /dev/sr1=imagefile :

My ext3 is ok as source for image files.
My reiserfs is not. ":-( write failed: Invalid argument".
Mangling #ifdef O_DIRECT in growisofs.c enabled burning from
that reiserfs too.
Only good i watch other people's problems on this list. :))


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Request for cooperation with all burn backends

[scdbackup]

Hi,

[EMAIL PROTECTED] wrote:
> "Very portable" almost alwas == "equally crippled on all platforms".
> I'm so tired of 'very portable' software.

A general locking facility would have to be system
dependent in respect to device identification and
naming.

All other aspects, especially the generic locking aspects
can be done in a portable way. TCP/IP and file system access
are portable concepts.


> I like the idea of having a convention-- but I would argue against it
> locking down devices against all access.  A CDROM device is perfectly
> capable of answering, eg, ' are you a cdrom?' whil e burning.  I
> realize that deciding what access is 'safe' is underspecified right
> now.

A big problem is that it is unclear which ioctls and
what SG_IO payload is safe and what possibly disturbs
ongoing burns.
I had a significant increase in DVD misburns as long as
libburn opened and inquired the drive for its bus scan.

Libburn's bus scan is an original design feature. Its
suppression was a matter of heart to me and lead to my
current involvement.
Nevertheless the main usage model for libburn with
interactive programs would include such a bus scan with
each program run. Even multiple scans per run would make
sense.

So i need to make it safe against other libburn instances
and  want to make it mutually safe with the other burn
programs.


> > Note that it doesn't have to be /dev/sg.
> 
> /dev/sg is dead.  Long live SG_IO.

What about SG_IO via /dev/sg ? :))


> I will not be obeying O_EXCL in cdparanoia, at least in its current
> form.  However, I also want to make cdparanoia safe in the context of
> cdrom devices burning

The charms of O_EXCL do not outweight its disadvantages,
indeed. (But for now it works for me. That outweights much.)

The general solution still seems to be a systemwide central
locking service which manages tickets about devices
without touching them.
The burn programs may decide on their own which of their
activities need such a lock ticket or what they deem to
be absolutely safe towards interference with others.

It is clear that all participants of the locking service
need a common naming system (OS specific) and that the
service must not be prone to stale locks or race conditions.

Open questions:

What is the cheapest and most widely available
connection mechanism which allows the server to hand
out lock tickets and to learn about the demise of
a client ?

How do our needs intersect with services provided
by HAL, resmgr et al ?
(For resmgr the answer is rather negative. by now.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Request for cooperation with all burn backends

[scdbackup]

Hi,


Andy Polyakov wrote:
> Have you seen resmgrd?

I found this overview of 2006-09-29:
  http://forgeftp.novell.com//resmgr/web/README.html
which differs a bit from the impression i got from
the SuSE 9.0 man pages. 

One could execute program
  resmgr lock /dev/xyz
and then open the device by normal means, possibly even
with O_EXCL.


Obstacles:

I can see no guarantee that a lock automatically vanishes
when the obtaining process ends, or that a "stale" lock
is recognized with sufficient probability.

Like O_EXCL this seems to lock device file inodes and not
devices. Thus /dev/sr0 and /dev/sg0 might be not coordinated.

The sysadmin has to set up an appropriate resmgrd
configuration before this. 

For us programmers it would be nice to know the resmgr
protocol and thus to get rid of forking an external
program. (A study of resmgr client code should help.)


Conclusion:

For our purposes resmgr is inferior to a working O_EXCL
lock. Except its possible acceptance with auto-mounters.

The current resmgr usage model seems to rather invite
the user to lock the device before growisofs, cdrecord,
wodim or cdrskin get started.

With a shell trap it should be possible to get this
end-user-safe. At least all experiments could be done on
shell wrapper level without changeing the code of the
participiating burn programs.

I now consider to offer this locking on the level of my
backup tool. Maybe it helps against automounters.

But with libburn i am quite unhappy about the outlook
on resmgrd. Neither can i assume to have it set up
properly on the majority of systems, nor does it really
ensure that i do not suffer from outdated locks.

A server with a persistent connection to the client
would be an appropriate implementation of our locking
demands. This server could revoke the lock as soon as
the connection to the client ends.
resmgrd is not designed to fulfill this task, i fear.


Further ideas:

Next i will try to find out wether HAL would be of more
help.

I consider to combine the naming scheme of my own lock
file experiment with a simple server rather than with
persistent files on disk.
The naming scheme hopefully coordinates devices and
not device file inodes. At least with SCSI- and ATAPI-
burners on Linux:

/dev/srN, dev/scdN, /dev/sgN get mapped to
  "scsi_${host}_${channel}_${id}_${lun}"

other device file paths get mapped to
  "rdev_${major}_${minor}
with the device numbers obtained from struct stat.st_rdev .

I believe this scheme is extensible enough for other
operating systems.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Request for cooperation with all burn backends

[scdbackup]

Hi,

> > Is it possible we define a common locking mechanism for drives
> > which does not depend on hardly documented Linux O_EXCL ?
> > Something simple and very portable would be needed. 
> 
> As for locking, or rather serializing access to [relevant] devices. 
> "Very portable" customarily means support for different operating 
> systems.

I tested growisofs with an advisory locking system based
on lock file naming conventions, unique owner ids and 
synchronization by waiting and verifying survival of owner
ids.

In principle it works - if there weren't all the exit()
in growisofs.c which do not play well with the need to remove
a lock file when work is done.


> Doesn't this kind of doom all "very portable" attempts as 
> simply unachievable?

It turned out to be quite obtrusive on growisofs code,
indeed. It gave up that idea for now. Especially since
Joerg seems to be not convinced of it either.


> Secondly. Why do you address back-end developers?

Because i joined that club as junior member by accident.

> Is it really a problem between recording programs?

It is especially a problem between growisofs and libburn
on my 2.4 system.

- growisofs burns of DVD+RW experience data damage in about
25 % of the cases after libburn did a bus scan on the burning drive.

- growisofs burns of DVD-RW stall libburn bus scan as soon as the
active drive is enumerated. Affected growisofs burns have about
50 % probability to be damaged.


> Isn't auto-mounting/-playing facilities 
> interfering with ongoing recording *bigger* problem? So if you want to 
> make the noble attempt and spend some time convincing developers time is 
> better spent talking to that developers. IMHO that is:-)

Well, after i proved my Web 2.0 skills by forging a lock
alliance of cdrtools, dvd+rw-tools, cdrkit and libburn
i will probably approach the auto-community for joining
our convention. :))


> I think that all 
> attempts to achieve the goal *purely* in user-land are doomed. 2.6 
> O_EXCL on block device appears to be sufficient for intended purpose and 
> I personally would rather prefer it back-ported to 2.4 than some 
> user-land facility.

O_EXCL locking is promised for 2.4 in the Linux sg HOWTO :
http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/open.html

I can offer a patch of 100 to 150 lines in growisofs.c
to achieve locking of /dev/srN or /dev/scdN via the
corresponding /dev/sgM.

Since i implemented that on my system i am free of trouble 
between growisofs and libburn.
I published the test version (loudly declaring itself as
inofficial hack) on the [EMAIL PROTECTED] mailing list
in the hope of some test results ... then i wanted to approach
you.

No echo. Everybody is on 2.6 already.

See diff -puN at
http://scdbackup.sourceforge.net/dvd+rw-tools-7.0.tsA60930.diff.txt

The complete package for testing 
http://scdbackup.sourceforge.net/dvd+rw-tools-7.0.tsA60930.tar.gz

My own tests on kernel 2.4.21 showed no problems.


> Note that it doesn't have to be /dev/sg. Even though different, both 2.4 
> and 2.6 provide interfaces for passing SCSI commands from user-land 
> through /dev/cdrom. Well, I have to admit I've never tested 
> CDROM_SEND_PACKET interface for non-data recordings... Did libburn 
> developers do?

libburn is using /dev/sgN with N out of {0..31} and /dev/hdX with
X out of {'a'..'z'} . Theoretically they could be mixed but in
practice /dev/sgN is for 2.4 with ide-scsi and /dev/hdX is for 2.6.
Both device families are used via the same SG_IO ioctl calls.

I did not thoroughly explore the transport and drive
command level yet. Not to speak of the more artful matters of
disc, session, and track semantics. (Most need for work is
currently in the usability aspects of the library.)


> To summarize. My vote goes for block device addressing,

We both use /dev/hdX on Linux 2.6 and locking seems to work fine.
(Allthough i believe O_EXCL locking should happen earlier
in growisofs.)

> back-porting of  O_EXCL to 2.4

Please consider above locking proposal via /dev/sgM.

It should keep away trouble with libburn and hopefully with
cdrecord and wodim. libburn and cdrecord do respect their mutual
locks on kernel 2.4. I tested that several times by accident.


> and convincing auto-mounting/-playing developers to stick 
> to it.

For now i would be glad to see Linux 2.4 mutual exclusion working
as it does on my own system now. The eventual abort of growisofs
comes a bit late but elsewise it seems to be ok.


> Note that there 
> are left-overs from experiment with resmsg in dvd+rw-tools code [look 
> for dev_open], so in case of alternative outcome,

I will have a look at resmgrd (and its relation to HAL
and D-Bus). It could be a model example of a locking service
and one could try to make an implementation on base of it. 
Such a proposal could be acceptable to automounters, too. 


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dvd+rw-tools 7.0: iso burning problem

[scdbackup]

Hi,

> [...] problem with ext3 implementation under 2.4 [...]
> It remains mystery why it was not noticed earlier by 2.4 users.

On my 2.4.21 kernel SuSE 9.0 and ext3 based /home there
is no problem with growisofs 7.0 and this command:

  growisofs -Z /dev/sr1=/home/fertig.iso

Shrug.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Request for cooperation with all burn backends

[scdbackup]

Hi,

> > which does not depend on hardly documented Linux O_EXCL ?
> > Something simple and very portable would be needed. 
>
> - Linux has a silly problem caused by device aliasing:

Yeah. But *that* i could circumvent.
The drivers know the SCSI quatruple (Host,Channel,Id,Lun)
and by that i can determine the matching sr for my sg.

Now with that info in hand i would only need a central
instance which tells me wether some other burn process
works on a thing with the same info.
That's what O_EXCL fails to do on sr with my oldish kernel.

I want a new more reliable central instance for that
in user space. A convention of burn backends so they
don't spoil each others burn.

Of course that thing will not save us from automounters
as long as they do not join our convention. But how
should they - as long as there is no convention ?


> - Record Locking only works on files.

I would anyway prefer to have no system locking mechanism
involved but only vanilla file operations.

link(2) and rename(2) can make a file appear quite atomicly.
The only race condition would be the asynchronizity between
lookup of not-yet-existent lock file and creation of the own
lock file.

For that i got a solution from the mid 1980s. 
A lock is obtained this way:
- lookup the lock file (have lost locking contest if it exists)
- create lock file with on id stamp as content
- wait three seconds
- lookup lock file and check wether own id is still there
  (if not there any more: have lost locking contest)

The 3 seconds were sufficient for NFS on a 10 Mbit LAN
with 50 workstations of 25 MHz each. We could wait less
than a second for that.

Lock files have names of form:

  /tmp/burner_backend_lock_${info_code}

Each burner device leads to a unique $info_code.


> If Linux would make [...]

Linux won't make. We need to make.

Linux is there and will be there.
The alternative is not Solaris but Vista, i fear.


HAL could probably do. Its server would be ideal.
But we should strive for something much more simple.

My porposal is:

- Above file synchronization protocol which will be
  very portable.

- A info_code convention which for now covers:

  - SCSI on Linux (and probably on most other systems)
  ${Host}_${Channel}_${Id}_${Lun}
All four numbers as plain decimals with no leading 0s.

  - ATAPI on Linux (and on other systems ?)
  ${stat.st_rdev}
As hexadecimal number but without trailing "0x".
To my knowledge there is only one (Major,Minor) device
number pair per ATAPI burner in Linux.

  - transports of your choice on systems of your choice
(currently i only have to deal with above two)


Thus if cdrecord wants to access burner "0,1,0" it looks up
${Host}_${Channel}_${Id}_${Lun} (how is channel+id related
to cdrecord target, btw ?) and attempts to lock via

  /tmp/burner_backend_lock_0_0_1_0

growisofs using /dev/scd1 would obtain the same quatruple
by SCSI_IOCTL_GET_IDLUN and compute the same file address.
The same for cdrskin using /dev/sg1 .

With ATAPI, growisofs and cdrskin use both "/dev/hdc"
and would come by a simple stat(2) to a file address like

  /tmp/burner_backend_lock_300

cdrecord would have to find a way to come from "ATA:1,0,0"
to "/dev/hdc" resp. the device number.
If you know a characteristic info of a ATAPI burner that
is easier to obtain for cdrecord: make a proposal.


> What you mentioned here is highly Linux specific and does nto help
> to find a OS independent way.

The info conventions for the file names can become OS specific,
i confess. Let's see how many OSes have no Host,Channel,Id,Lun
for SCSI and no unique device number for ATAPI burners.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Request for cooperation with all burn backends

[scdbackup]

Hi,

this is a request towards all developers of burn backends.

Is it possible we define a common locking mechanism for drives
which does not depend on hardly documented Linux O_EXCL ?

Something simple and very portable would be needed. 
Advisory locking would be sufficient, i think.
It should cover the problem of one SCSI address having several
"official" device files. Thus i would propose a lock file which
contains characteristic unique info about the burner. That would
also help with device aliases that are no symbolic links.

For SCSI that unique info could be (host,channel,id,lun) as
returned on Linux by ioctl(SCSI_IOCTL_GET_IDLUN), for ATAPI
i would appreciate a similar proposal.

The mechanism on each OS would be allowed to be OS-specific
since it is supposed to be used only within one system at a time.
It would not have to be totally safe against race conditions.
It should suffice to write the own process id into the locking file,
wait a due time, and check wether the own id survived.


My motivation currently is about growisofs and /dev/srN :

I had the ito open(2) O_EXCL those /dev/srN and /dev/scdM
which have the same SCSI address as the /dev/sgK used by libburn.

But while running on my SuSE 9.0, 2.4.21 kernel :
   growisofs -Z /dev/sr0=/dev/fd/0

i can still sucessfully do in another process
   open("/dev/sr0", O_EXCL|O_NONBLOCK|O_RDWR);

A bold try to run grwoisofs on  -Z /dev/sg0  yielded:
   :-( unable to open("/dev/sg0"): Block device required

With cdrecord the situation is better since we both use /dev/sgN
and thus mutally exclusive locking works for my 2.4.21 system.

I inserted a test print into version 7.0 of growisofs.c

 * For reference, I can't do it earlier as exclusive lock
 * could have been granted to mounted file system, the one
 * we've tried to unmount just a moment ago...
 */

 /* ts A60927 : What devices get locked ? */
 fprintf(stderr,"cdrskin_experimental: ioctl_device= '%s'\n",
 ioctl_device);

int fd = open64 (ioctl_device,O_RDONLY|O_NONBLOCK|O_EXCL);
struct stat64 sb,sc;

and this prints:

   cdrskin_experimental: ioctl_device= '/dev/sr0'

In http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/open.html i read
   "The combination of O_RDONLY and O_EXCL is disallowed."
but that's for /dev/sg* not for /dev/sr* . 
In http://sg.torque.net/scsi/SCSI-2.4-HOWTO/index.html i cannot
find anything about open(2) or O_EXCL.

Is it possible that O_EXCL does not work with sr on 2.4 kernels ?
It works fine with sg on my 2.4.21.

I tried in growisofs.c without success:
   int fd = open (ioctl_device,O_RDWR|O_NONBLOCK|O_EXCL);

Locking worked with hardcoded /dev/sg0 :
   int fd2 = open ("/dev/sg0",O_RDWR|O_NONBLOCK|O_EXCL);

(at the price that cdrskin could not resolve SCSI address "0,0,0"
any more, because /dev/sg0 refused to tell.)

I could provide a translator from /dev/srN to /dev/sgM (which only
works on unlocked devices) but somehow the whole mess makes me think
that a common portable locking mechanism of burn programs would
be the better solution.

I am open to any proposal.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dvd+rw-tools update [7.0, Blu-ray, Mac OS X]

[scdbackup]

Hi,

congrats to new dvd+rw-tools-7.0 .
Runs out of the box.

"UBU" = unit buffer usage ?


Blu-ray ... BD-RE ... 25 to 50 GB ...
I just got a new DVD DL burner by incident.
Did i miss something ?

Googling for prices ...  LG Electronics GBW-H10N ...
you get 2 TB of RAID for that ... Pioneer BDR-101ABKS
... Sony BWU-100A ... Panasonic SW-5582 ... same.
Media: Three 25 GB BD-RE media =
One DVD burner + 20 DVD+RW (= 80+ GB).

Well, in two years, maybe :))
Great to know that the software is prepared.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: a NERO user familiar with backing up data on multisession CDR, how do I do it in Linux too?

[scdbackup]

Hi,

> ... now switched to Linux ... multi-session ... CDR ...

I myself am not into multi-session. So a few general
hints. (And a test wether i'd could help myself.)

A bit an outdated HOWTO (google for "cdrecord howto" or "mkisofs howto")
  http://www.faqs.org/docs/Linux-HOWTO/CD-Writing-HOWTO.html#ss4.18
points to original docs README.multi contained in cdrtools.

That would be this URL:
  ftp://ftp.berlios.de/pub/cdrecord/README.multi

(Looks a bit more detailed than the examples which i dimly
 remember. Probably should explore the steps manually
 and then write your preferred method into a shell script.) 

By further googling i found (german)
  http://www.willemer.de/informatik/unix/licd.htm
with examples.

The "." is the data source (current working directory).
You would replace it by the addresses of your files or directories.
First session:
  mkisofs -J -R -o ../image.iso .
  cdrecord -v speed=2 dev=0,3,0 -multi ../image.iso

Following sessions:
  TRACKPOS=`cdrecord -msinfo dev=0,3,0` 
  mkisofs -J -R -f -o ../image.iso -C $TRACKPOS -M 0,3,0 .
  cdrecord -v speed=2 dev=0,3,0 -eject -multi ../image.iso

The final session shall leave out cdrecord option "-multi".
(If you stumble over the strange quotation marks,
 on a bash or ksh shell a more modern expression would be:
  TRACKPOS=$(cdrecord -msinfo dev=0,3,0)
)

With modern hardware you may combine mkisofs and cdrecord in
one pipe command without any image file buffered on disk:
  mkisofs -J -R -o -  ...your.files.and.dirs...  | \
  cdrecord -v driveropts=burnfree speed=24 dev=ATA:0,0,0 -multi -

(This example shows more modern parameters. If you need help
 with details of mkisofs or cdrecord, read
   http://cdrecord.berlios.de/old/private/man/cdrecord-2.0.html
   http://cdrecord.berlios.de/old/private/man/mkisofs-2.0.html
 and if you feel well preprared, ask for further help here.)


If you need help from the author of mkisofs and cdrecord,
it would be wise to upgrade to the newest version:
  ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a14.tar.bz2
But any Linux distribution should offer sufficient older
versions of mkisofs, cdrecord and their man-pages. The
multi-session feature is not new at all.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

I really found a little bug in mkisofs 2.01.01a13

[scdbackup]

Hi,

> @@ -583,6 +583,7 @@
> +++ ./getargs.c Sa Sep  9 15:58:33 2006
> + argp = sargp;

... cdrtools-2.01.01a13/libschily/getargs.c ...
For me it is rather line 566. 

Now i seem to have a problem with the build dependencies:

  $ make
  make[2]: Entering directory `/home/thomas/cdr/cdrtools-2.01.01a13/libschily'
   ==> COMPILING "OBJ/athlon-linux-cc/getargs.o"
   ==> ARCHIVING "../libs/athlon-linux-cc/libschily.a"
  ==> RANDOMIZING ARCHIVE "../libs/athlon-linux-cc/libschily.a"
  ...
  ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/mkisofs"
  make[1]: Entering directory `/home/thomas/cdr/cdrtools-2.01.01a13/mkisofs'
  make[1]: Nothing to be done for `all'.
  make[1]: Leaving directory `/home/thomas/cdr/cdrtools-2.01.01a13/mkisofs'
  ...

The bug is still there, of course:

  $ mkisofs/OBJ/athlon-linux-cc/mkisofs -J -joliet-long -R -D -graft-points 
/u/FERTIG >/dev/null
  Bad Option '-joliet-long' (error -1 BADFLAG).
  ...

Next i try to use some force:

  $ rm mkisofs/OBJ/athlon-linux-cc/mkisofs
  $ make
  ...
==> MAKING "all" ON SUBDIRECTORY "SRCROOT/mkisofs"
  make[1]: Entering directory `/home/thomas/cdr/cdrtools-2.01.01a13/mkisofs'
  ==> LINKING "OBJ/athlon-linux-cc/mkisofs"
  make[1]: Leaving directory `/home/thomas/cdr/cdrtools-2.01.01a13/mkisofs'
  ...

and then i test again:

  $ mkisofs/OBJ/athlon-linux-cc/mkisofs -J -joliet-long -R -D -graft-points 
/u/FERTIG >/dev/null
  ...
  64496 extents written (125 MB)

All ist well. Thanks.


So this make-dependicy problem could be the next - even more
exotic - bug to report ?


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

I really found a little bug in mkisofs 2.01.01a13

[scdbackup]

Hi,

i think i found a newly introduced bug in mkisofs 2.01.01a13. 

This command does work:

  $ mkisofs -J -R -D -graft-points /my/dir >/dev/null

But this one does not any more:

  $ mkisofs -J -joliet-long -R -D -graft-points /my/dir >/dev/null
  Bad Option '-joliet-long' (error -1 BADFLAG).
  Usage: mkisofs [options] file...

  Use mkisofs -help
  to get a list of valid options.
  $ mkisofs -help 2>&1 | grep joliet-long
-joliet-long   Allow Joliet file names to be 103 Unicode characters

-joliet-long is still in help text and man page.
So if it is to be dismissed, the docs need to be adjusted.

I can hardly evaluate wether -joliet-long did ever bring
positive results. But mkisofs-2.01.01a09 has no problem
with that setup. (scdbackup does not use -J or -joliet-long
by default, because some older mkisofs did not do so well
on -J. Actually i use it in the hope to reproduce that
reported bug.)

I ran a backup with a13 using -J but not -joliet-long.
It turned out fine. Mountable, diffable. (Usually i verify
a stream checksum of the whole image. But to test mkisofs
one has to diff the single files.)


CD-RW tests are done, CD-R will have to wait for an opportunity.
Right now cdrecord-2.01.01a12 writes a DVD+RW.
... done ... verify ... 12 minutes later: OK

I leave out DVD-RW tests because my drive kills my few DVD-RW
media on blanking. The survivors are all in state "restricted
overwrite" for use with growisofs. As long as i leave them in
that state, they are fine. Formatting them to "sequential" mode
or use with cdrecord-ProDVD kills them quite reliably.
It's the drive, i guess. (shrug)

I'm quite done. Configuration, daily use ... all ok.
Just that exotic option. Hey. I can prove i really tested. :))


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Some intermediate thanks to Joerg Schilling

[scdbackup]

Hi,

> > I would need to look for my Suse-9.x HDD again
> Don't bother. SUSE 9.0 has been discontinued ages ago.

But *i* am not discontinued ! :))


Pun aside:

My computer is two years old and scheduled for another two.
Lots of others out here are in similar stages of their life.


If i want to give the users of scdbackup free choice of
burner programs then i need a place where to i can point
them for cdrecord.
The more simple, the better.

A fixed URL of the currently advised source tarball would
be very helpful for that. Then scdbackup's README can point to
it permanently.
Like:
"
Get current cdrtools sources from
  ftp://ftp.berlios.de/pub/cdrecord/advised/cdrtools.tar.gz
Unpack, go into toplevel directory "cdrtools-...", execute "make".
"

Best would be a tarball with binaries of cdrecord and mkisofs,
with their man-pages and with a README that points to the
URL of the sources. (Plus copyright, license, et al.)
Like:
"
Get current cdrtools Linux binaries from
  ftp://ftp.berlios.de/pub/cdrecord/minipacks/cdrtools-i686-linux_2_4.tar.gz
Unpack, put binaries and man pages at places of your discretion.
"

According to my experiments
  cdrecord-prodvd-2.01.01b03-i686-pc-linux-gnu
runs on SuSE 7.2 (2.4.4), on SuSE 9.0 (2.4.21) and on RIP 14.4
(2.6.14). I guess that others tested the same binary on other
outdated and on current distros.
A pack of such binaries from the current sources would be convenient.
(I do not know how Joerg does it. They are not gcc -static.)


Since we have that strange competitive situation now, we
should simply let our users make the choice.

scdbackup-Thomas will point to all three CD burner programs.
cdrskin-Thomas will have a static x86-binary ready for those
who want to quick-try cdrskin.
cdrkit-people (who happen to maintain cdrskin on Debian) will
hopefully allow a download that is similarly easy to describe.
Eventually they can rely on their distribution power and wodim
will appear automatically on newly installed machines soon.


For scdbackup project, the current situation is a great improvement
over the situation a year ago. I only regret that it is combined
with so much dirt flying around in user discussion forums.
That's why i started this thread here.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Some intermediate thanks to Joerg Schilling

[scdbackup]

Hi,

> Mmm, strange. cdrtools did just compile wihout any warning
> on Suse 10.0

Now you made me curious. My SuSE 9.0:
Linux * 2.4.21-215-athlon #1 Tue Apr 27 00:53:38 UTC 2004
i686 athlon i386 GNU/Linux

  $ bunzip2 &1 | tee -i ../compile.log
W A R N I N G   Messages like:

  [...a minute on a 1900 MHz Athlon ...]

  /usr/lib/gcc-lib/i586-suse-linux/3.3.1/../../../../i586-suse-linux/bin/ld: 
cannot find -lscg
  collect2: ld returned 1 exit status
  make[1]: *** [OBJ/athlon-linux-cc/skel] Error 1
  [...]
  $

I know this since i have my SuSE 9.0.
In ../compile.log my vim finds:
  ==> COMPILING "OBJ/athlon-linux-cc/scsihack.o"
  In file included from scsihack.c:131:
  scsi-linux-sg.c: In function `sg_settimeout':
  scsi-linux-sg.c:1195: error: `HZ' undeclared (first use in this function)
  scsi-linux-sg.c:1195: error: (Each undeclared identifier is reported only once
  scsi-linux-sg.c:1195: error: for each function it appears in.)

I carry my little private patch (see cdwrite archives July 2004)
from my previous recent cdrecord to the new one:
  $ view ../cdrtools-2.01.01a09/libscg/scsi-linux-sg.c
[...]
/* added by [EMAIL PROTECTED] A40724 - A60515 .
   Guessed. Nonportable. Do not use ! 
*/  
#ifndef HZ 
#define HZ 100
#endif  
  $ vi libscg/scsi-linux-sg.c
/* added by [EMAIL PROTECTED] A40724 - A60908 .
  $ make

Now it is fine. No further problem. (May memories are false,
probably.)

  $ find . -name cdrecord
  ./cdrecord
  ./cdrecord/OBJ/athlon-linux-cc/cdrecord
  $ ( cd ./cdrecord/OBJ/athlon-linux-cc ; ls -l cdrecord )
-rwxr-xr-x1 thomas   thomas 409166 Sep  8 21:13 cdrecord
  $ su
  # ./cdrecord/OBJ/athlon-linux-cc/cdrecord -scanbus
  Cdrecord-ProDVD-Clone 2.01.01a12 (i686-pc-linux-gnu)
  Copyright (C) 1995-2006 Jörg Schilling
  Linux sg driver version: 3.1.25
  Using libscg version 'schily-0.8'.
  scsibus0:
  0,0,0 0) 'HL-DT-ST' 'DVDRAM GSA-4082B' 'A201' Removable CD-ROM
  [...]

Joerg. You see that i damn trust your honor.
You are superuser on my box. Personally.
In case of mishap i'll test the quality of my backups.

Urm ... why does it say 2.01.01a12 ?
There is a AN-2.01.01a13 in the top directory.
... aha ... no new cdrecord features since a12.


Well, what did i want to test soon ?
(Currently i'm hopping between my old and my new
 machine. The old running 2.6, the new 2.4. I got
 some need for whoami clones like whereami, whatsnext.)
I wanted to RTFM of mkisofs.

  $ ./mkisofs/OBJ/athlon-linux-cc/mkisofs -version
  mkisofs 2.01.01a13 (i686-pc-linux-gnu)
  $ find . -name mkisofs.8
  $ man ./mkisofs/mkisofs.8
  [...]
   mkisofs will create any directories
   required such that the graft points  exist  on  the  cdrom
   image  -  the  directories do not need to appear in one of
   the paths.  By default, any directories that  are  created
   on the fly like this will have permissions 0555 and appear
   to be owned by the person running mkisofs.   If  you  wish
   other  permissions  or owners of the intermediate directo­
   ries,  see   -uid,   -gid,   -dir-mode,   -file-mode   and
   -new-dir-mode

Again, i end up at -new-dir-mode which is a bit what i would
need ... but not quite exactly:
   -new-dir-mode mode
  Mode  to  use  when creating new directories in the
  iso fs image.  The default mode is 0555.

I would need an option which tries to obtain the mode from the
directories in the source path. This currently happens only with
the leaf directory of the source path and with its sub tree.
  /x/y=/a/b/c/leaf
(I will check this again.)

"leaf" transfers its mode to ISO:"/x/y" , but the mode of "c"
would be what i wish for ISO:"/x".

If there is a way to achieve this, then give me an example, please.

If not: well, i needed a workaround anyway. So i store a list
with all directories and their permissions in the backup,
as well as a shell script, which would restore all those
permissions.


It will be a few days until i can give the new cdrecord 
and the new mkisofs a full regression test with scdbackup.
I'll report.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Some intermediate thanks to Joerg Schilling

[scdbackup]

Hi,

> > Well, compiling cdrecord on SuSE 9.0 is a bit cumbersome ...
> 
> What kind of problems do you have?

I remember an undefined HZ caused by having a semi-100
and semi-1000 Hz kernel. I dimly remember that i had
another issue (which will bite me again and remind me)
when i compiled your first source release of DVD support
a few months ago.
(scdbackup's default for DVD is growisofs but cdrecord
can be used too. I tested that - when i was not yet so
completely overwhelmed by my newer roles.)

 
> I would need to look for my Suse-9.x HDD again

Oops. I did not want to instigate hardware efforts.
I always was able to compile cdrecord, somehow. But my users
are a bit less skilled with reading protest messages of gcc.
For them cdrecord-ProDVD was a viable alternative to
compiling.


> > This i would use to chop oversized files (>650 MB, >=2 GB)
> > without the need for buffering the parts on disk.
> > (I will be able to tell exact sizes in advance.)
> 
> I don't understand.

Use case:

With planning a backup on CD, my scdbackup encounters a
file of 1 GB size. It won't fit. scdbackup needs a to do
a workaround. So the user will get a chopped file. Better
than nothing. Easy to restore. cat is my friend.

Currently scdbackup copies the first 640 MB out of that file
into a new file in a disk buffer directory. Then this disk
file is given to mkisofs. 
-graft-points allows me to put it back into its appropriate
directory in the ISO image. A name suffix tells the chunk number
and the total number of chunks.

The other 384 MB are later given to the next run of 
mkisofs | cdrecord for the next CD volume. Together
with other files to fill up.

The problem with this approach is: 
- the user needs buffer space on disk 
- i must protect those buffered files from spying and alteration
  (backup is a matter of privacy and security).

With DVD, the problem is the same because i better do not
expect a file of 2 GB or more to be readable on all systems.
The buffer space needs are even larger. The user has to provide
a full DVD size because mkisofs wants to see all the chunks
of a volume simultaneously.

My proposal would allow to generate them one by one and
to pipe them into those new super-complicated pathspecs.
(They are an imposition on you, i confess. Let them ripe
a while on your todo list ... :)


> > This feature would also allow very interesting stunts like
> > file-by-file compression and/or encryption in a plain
> > ISO tree.
> 
> There is a non-standard (Linux only) RR extension in mkisofs for
> compression and it my be that we will support this in future on Solaris.

Interesting. What's the option name ? ... -z ?
Ahum ... hey, that's something for my own todo ...
... mkzftree ... ahum ... again a reason to have
disk buffer ? Will i never get rid of that ? :))

A usage example would help with the -z paragraph in
man mkisofs (as of cdrtools-2.01.01a09).
Like:
"
  mkisofs /x/=/a/b /y=/c/d
can be done with compression by
  mkzftree ...
  mkisofs ...
"
I will have to do some experiments.


But my proposal is more general and it would isolate you from
many particular enhancement wishes which could be fulfilled
on user level then. Each of those pathspecs would be a 
stdin-inlet for arbitrary tricks and filterings. We all
know the power of the pipe.
I can imagine one mkisofs employing a dozen subsequential runs
of star to create an ISO image with a dozen star-balls in it.
On the fly.
star can stand a few padding 0s. I know for sure. :))

Each of the pathspecs would result in one file in the ISO
tree. The file's size would be predicted already at start
of mkisofs. (Although mkisofs should expect the input having
a deviating size and then correct that deviation brutally.)

Whatever. You got your own priorities. For scdbackup
it is most important that the old features are kept alive.
For that i will test soon.


> However, correct hard link handling and File size > 4 GB would be more
> important.

These are important features for scdbackup, too.
The nearer the mkisofs result comes to a normal Linux
filesystem, the better it is for backup purposes.
(You did a lot for that in the last years. I noticed.)

I would deem >4GB files in mkisofs very valuable. But i could
hardly dare to use that feature as default for quite a while.
There is lots of ISO reader software out there which does not
even cope with >=2 GB.


> > Copy the attributes of implicitely given directories into
> Please check the recent mkisofs first

I take this as a friendly RTFM. :)
Give me a few days time to follow that advise.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Some intermediate thanks to Joerg Schilling

[scdbackup]

Hi,

> It seems that I have been cicked out from this list by Debian.

Indeed ?!
That would be a very unwise and critic-worthy move.

cdwrite@other.debian.org is a place where one can meet you and
Andy if there are problems with the two main burner apps on
Linux. This place came in very handy. Quite calm, few spam,
no persistent trolls, ...

Be so kind and try a re-subscribe here. If you really are
banned, then the deciders should state this publicly, please.
I mean, one thing is to cease cooperation, the other is to
exclude you from public technical discussion.

And this i say with all the roles which stick to me right now

- developer of scdbackup, who recently asked the Debian
  cdrkit project for migration hints about wodim.
  (scdbackup uses cdrecord as default, but will support wodim
   and already does support cdrskin under their real names.)

- developer of cdrskin which tries to provide a second source
  for the services traditionally provided by cdrecord.

- co-developer of libburn.pykix.org, which *really works* for
  cdrskin ... a bit by accident, as i found out meanwhile.
  (Well, this shall change. The accident - not the work.)


To the public:

I am Joerg Schilling's user, i am his imitator, i am his competitor.
And look: here are two CD-germans who can still talk politely to
each other. It is not impossible.

Currently i want to believe in some accidental misunderstanding.
(Nevertheless this letter goes as copy to Joerg directly.)


> If you like to help me testing, please check the latest
> cdrtools-2.01.01a13
> ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a13.tar.bz2

Well, compiling cdrecord on SuSE 9.0 is a bit cumbersome ...

> completely reritten command line parsing and with the new find(1) features.

... but that should indeed be tested.

You could help me with that - and help my users -
by providing a Linux binary as portable as cdrecord-ProDVD
was. (How do you make that thing run on SuSE 9.0 and
on SuSE 7.2 ? I need to compile static to achieve this.
libc problems.)


> Note that the latst mkisofs now suopports find(1) expressions
> similar to star(1) via libfind.

I misuse it as archive formatter for backups, as i confessed
earlier. Thus i am mainly interested in making regression
tests wether the traditional core functionality is still ok.


I would have wishes towards mkisofs, but they are a bit exotic.

Number 1:
A pathspec which allows to graft in the output of a
program run. Defining target name in ISO image, maximum size,
even RockRidge attributes, and the program command line.
The size of output should be padded or truncated by mkisofs
to fit the announced size.
This i would use to chop oversized files (>650 MB, >=2 GB)
without the need for buffering the parts on disk.
(I will be able to tell exact sizes in advance.)

This feature would also allow very interesting stunts like
file-by-file compression and/or encryption in a plain
ISO tree.

Number 2:
Copy the attributes of implicitely given directories into
the RockRidge extensions (and/or Joliet). My problem is with
a pathspec like this one (option -R is set):
  /pics/animals=/home/user/pics/animals

I get exactly copied the rwx-permissions of "animals".
But its boss directory "pics" in the ISO image gets default
permissions.
RTFM tells me that i can explicitely set the default mode
for directories by -new-dir-mode. But rather i would need
an automat which copies the actual mode from "pics".

That is because scdbackup does not master a well prepared
CD publication but backups to a heap of CDs what it can find
on disk. No assumptions about the beauty of that tree allowed.
(I warn people of using ISO for operating system snapshots.)


Joerg, we'll stay in touch.
Although two of above three roles submit themselves to
strict chinese walling towards cdrecord source code.
No peeking. I will ask you - if i know a good question. :)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Some intermediate thanks to Joerg Schilling

[scdbackup]

Hi,

in the name of my project scdbackup and its CD burning users
i want to thank Joerg Schilling for providing the burn foundation
since my project started in 1999.

I commend Joerg for his software which still is the foundation
of scdbackup's core CD functionality, although i took substantial
effort to reduce that dependency during the last years.

For cdrecord, for mkisofs, for star: Chapeau (i lift my hat).


I still recommend the use of cdrecord for CD burning within scdbackup
although i have ready a replacement that covers my use cases nearly
as good.
So within the upcomming competition i can hardly take sides because
i have stakes with nearly any of the participating parties.
(I am even undecided what opinion i should have at all in private.)

For scdbackup, any program will do if it behaves roughly like 
cdrecord. Nevertheless i would be glad to point to an original
Joerg Schilling cdrecord binary ready for use on mainstream
Linux 2.6 without ide-scsi. Like i pointed to cdrecord-ProDVD.
Please take this as a sincere user proposal, Joerg.


This is no good-bye-Joerg letter at all. It is a reaction on the
ugly words which can be read about Joerg Schilling at other places
issued by totally unrelated bystanders.

On the other hand, this is no crtiticism of the newest fork.
Currently it looks like forking is far better than to further
escalate the quarrels. (Here i do have an opinion.)

So, for another few years: alltogether.

Oh yeah. Not to forget: Thanks to Andy Polyakov. 
Not to forget at all. Especially now. 


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problems when writing DVDs with growisofs

[scdbackup]

Hi,

for subscription:

List-Post: 
List-Help: 
List-Subscribe: 
List-Unsubscribe: 

probably you fell victim to false addresses on some web site.


> Short before end an I/O-Error happens and was logged to the kernel log
> file as:
>  attempt to access beyond end of device
>  hdd: rw=0, want=8388608, limit=8388604
>  Buffer I/O error on device hdd, logical block 2097151
> Then I umounted the device and uses dd to copy an image of the dvd to 
> my harddisk:
> I mounted the image via loop-device and tried again to cat all files
> to /dev/null which again fails as described above.

Up to this point i would say the DVD did not accept all
data that were sent to it. (Swallowed a last buffer full)

But...

> Then I used readcd to create an image of the dvd. Also this process
> does not report any error.
> I mounted the image via loop device and THIS time I was able to
> retrieve all files. They were identical to the originals.

Now the DVD-ROM driver of the operating system is under
suspicion. (We had and still have this effect with CDs.)

Compare the size of the images extracted by dd and readcd.
How much larger is the one of readcd ?


> I am near desparation. I cannot find the reason for this
> behaviour. Since I copy more valuable data as some dvb-t recordings to
> DVD I would be happy to have a reliable scheme how to copy
> successfully files to DVD+RW and other media.

The ill effects with CD readers are traditionally compensated
by generous padding. 300 kB are considered to be enough.

You may try to add a designated victim file to the ISO
image but better would be to split the jobs of mkisofs
and growisofs and to add the padding *after* the ISO image.
  mkisofs ... >buffer_file
  dd bs=1m count=10 if=/dev/zero >>buffer_file
  growisofs ... -Z /dev/hdd=buffer_file
or
  mkisofs ... >buffer_file | \
  let_through_and_pad_10_mb | \
  growisofs ... -Z /dev/hdd=/dev/fd/0

let_through_and_pad_10_mb would add 10 MB of zeros after
it first passed all stdin unaltered to stdout.
(I use the latter method in my backup tool.
Out of mere superstition i still pad 300 kB to DVDs.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrecord _used_ to work ... dropped support for Generic mmc2?

[scdbackup]

Hi,

> I can't write CD-R discs with cdrecord - it objects on the grounds of my
> giving it DVD media - but I'm feeding it CD-R blanks. 
> 
> CD-RW discs work just fine as do DVD-RW with growisofs.
> 
> I _used_ to be able to write CD-R - I have several as evidence from a
> couple of months ago. Since then I have changed nothing substantial. Same
> old CD writer, same old kernel, same old computer. [...]
> I tried different CD-R blank media (from el cheapo to expensive
> Verbatim). Same individual discs work on another computer at work having
> failed at home. [...]
> I tried several old and new versions of cdrecord [...]

The conventional hypothesis would be that something in your equipment
silently went bad. Since the refusal is so specific to CD-R, i would say
it is the writer device resp. its firmware.

What do you get from this ?
  cdrecord dev=... -atip 

My CD/DVD burner reports on a blank CD-R :
  Cdrecord-ProDVD-Clone 2.01.01a09 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling
  [...]
  ATIP info from disk:
Indicated writing power: 5
Is not unrestricted
Is not erasable
Disk sub type: Medium Type B, low Beta category (B-) (4)
ATIP start of lead in:  -11768 (97:25/07)
ATIP start of lead out: 359775 (79:59/00)
  Disk type:Short strategy type (Phthalocyanine or similar)
  Manuf. index: 64
  Manufacturer: MPO

(Needless to say that it burns CD-R nicely with various cdrecord versions.)


> ... or perhaps the hardware is on the way out - but how come I can write
> the (supposedly more-demanding) CD-RW and DVD?

I guess it just mis-identifies the media.
Like this:

> Profile: 0x0080 (current)
> cdrecord: Found unsupported 0x80 profile.


> Any ideas anyone?

You could invest 20 dollar into the experiment to buy and install
a cheap CD burner.

You could try cdrskin, a cdrecord compatibility wrapper
around libburn:
  http://scdbackup.sourceforge.net/cdrskin_eng.html

The library seems not to be very picky about the media type.
With a CD-R (24x is the drive's limit):
  $ cdrskin dev=1,0,0 -atip
  cdrskin 0.1.3 : limited cdrecord compatibility wrapper for libburn
  [...]
  cdrskin: status 1 burn_disc_blank "The drive holds a blank disc"
  cdrskin: burn_drive_get_write_speed = 4234  (24.1x)
  ATIP info from disk:
Is not erasable
1T speed low:  24 1T speed high: 24

With 4x DVD+RW inserted:
  $ cdrskin dev=1,0,0 -atip
  [...]
  cdrskin: status 1 burn_disc_blank "The drive holds a blank disc"
  cdrskin: burn_drive_get_write_speed = 5540  (31.5x)
ATIP info from disk:
  Is erasable
  1T speed low:  31 1T speed high: 31  

But i cannot recommend to try burning a DVD via cdrskin, of course.  {:)
Anybody who is trying this ... shall please report about the outcome  :))

I'm only the programmer of the compatibility skin, not of libburn
which does the work inside cdrskin. Thus i will not be of much help
when it comes to diagnosing the particular problem with your equipment.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools-2.01.01a09 released

[scdbackup]

Hi,

> Joerg Schilling wrote:
> Today, I happily announce new features and the release of the DVD-code
> into the OpenSource. 

Applause for this move !

Did you already decide the future fate of the ProDVD download directory
ftp://ftp.berlios.de/pub/cdrecord/ProDVD ?
It would still be useful for pointing people to untampered cdrecord binaries.
A set of  cdrecord-2.01.01a09  binaries at that place would be a fine thing.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Repeatability of mkisofs?

[scdbackup]

Hi,

>> Michael Shell wrote:
>> 3. mkisofs is embedding the output filename/path or the command line as
>>  it was invoked within the created image
> I wrote:
> I don't think so.

One can be certain and be wrong.

011   M   K   I   S   a   t   M   a   y   6   1
0110020   0   :   0   1   :   4   9   2   0   0   6  \n   m   k   i
0110040   s   o   f   s   2   .   0   1   .   0   1   a   0   3
0110060   -   l   -   a   l   l   o   w   -   l   e   a   d   i   n
0110100   g   -   d   o   t   s   -   R   -   D   .   .   .
0110120   /   t   e   s   t  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0110140  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

So it does record some command line arguments.
I am not sure wether the source path gets recorded. At least here
is written ".../test" and not "/u/test" as used by me.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Repeatability of mkisofs?

[scdbackup]

Hi,

> I keep track of the md5sums of all the images I burn.
> [...]
> So, I rebuilt a new image via mkisofs from the exact same
> directory structure used to create the old image. Now, the two images had
> the exact same byte count, but, much to my surprise, they differed with
> respect to their md5sums! Why is this?
> Several possibilities for the differing output files come to mind:
> 1. mkisofs somehow makes use of a random number generator

Rather unnlikely.

> 2. mkisofs is embedding or using the current time in the output

Quite certainly.

> 3. mkisofs is embedding the output filename/path or the command line as
>  it was invoked within the created image

I don't think so.


An experiment (at about 8:20 local time)

  $ mkisofs -l -allow-leading-dots -R -D /u/test | od -c >iso1.txt
  $ mkisofs -l -allow-leading-dots -R -D /u/test | od -c >iso2.txt
  $ diff iso1.txt iso2.txt

The diff result is short and in this case it it is typically about
a "09" replaced by a "12" on several locations in the images. This
seem to be cleartext date+time strings ("20060506082009" vs.
"20060506082012").
The same gesture is done with ASCII 9 and ASCII 12 at two spots
which i think are binary representations of the timestamp.

29,30c29,30
< 0101460   6   0   5   0   6   0   8   2   0   0   9   0   0  \b   2   0
< 0101500   0   6   0   5   0   6   0   8   2   0   0   9   0   0  \b   0
---
> 0101460   6   0   5   0   6   0   8   2   0   1   2   0   0  \b   2   0
> 0101500   0   6   0   5   0   6   0   8   2   0   1   2   0   0  \b   0
...
83c83
< 0114020   8   :   2   0   :   0   9   2   0   0   6  \n   m   k   i
---
> 0114020   8   :   2   0   :   1   2   2   0   0   6  \n   m   k   i
... 
118c118
< 0160340 005 006  \b 024  \t  \b   j 001  \n 027 001   0 004  \0  \0  \0
---
> 0160340 005 006  \b 024  \f  \b   j 001  \n 027 001   0 004  \0  \0  \0


I don't think there is an command line option to avoid this.
Solution ideas (i would prefer number 1):
- one could try to patch the resulting ISO image by identifying
  the time stamps (of which the value should be easy to guess)
  and replacing them by the old values.
- one could patch mkisofs so that it does use always the same
  dummy timestamp. There are several calls of time(2) which
  one would have to examine wether they are to blame for the
  differences.

This will not save you from the real life problem that file
system trees on disk change quite easily. Especially with 
Rock Ridge extensions you are likely to unexpectedly get a
different payload of the ISO image.

Probably you are better off if you record checksum information
about the single files contained in the image. It would be
much easier to judge wether a checksum difference is essential
or not.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: growisofs 6.1 fails to allocate shared memory beyond 16m

[scdbackup]

Hi,

> I'm trying to run growisofs 6.1 on Nslu2 device (with etch) it's small 
> device with low power consumption and with only 32M RAM:(
> I have tried to recompile debian source with smaller buffer size 
> WARN=-DDEFAULT_BUF_SIZE_MB=16 but i don't know how to check this buffer 
> size in complled executable.
> I have tried as root and as normal user and with ulimits too...
> Any help will be apreciated

I set the ring buffer size to 16 MB at run time by this option
  growisofs ...  -use-the-force-luke=bufsize:16M  ...
using a vanilla growisofs as it emerges from Andy's original
dvd+rw-tools-6.1 via command make.

dvd+rw-tools-6.1/growisofs.c  states that minimum size is 
1 MB and that only powers of 2 are permitted (i.e. 2M, 4M, ...).


For checking memory consumption of growisofs (on Linux) i would 
execute something like
  ps -eo pid,size,vsize,ucmd | fgrep growisofs
while growisofs is running. 


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to tell if mounted media is CD-R, CD-RW or CD-ROM?

[scdbackup]

Hi,

 Looks like Joerg is not amused by some bug-or-feature of
 your Linux.
>>>
>>> Take out the "your" part :-)
>>
>> Ok. Neither mine nor yours.
> 
> I meant Joerg has problems with linux in general (and I tend to agree
> with him as regards to linux scsi infrastructure), not any specific
> distributions (mine or yours).

It is often about certain kernel versions and certain
intermediate states of the infrastructure.
After all, the "botch" text was new to me.


> However, i found out that even if I don't get the "erasable" strings,
> if I add "-v" I get the same info in another way (the "current
> profile" stuff)
> 
> So immediate problem is solved.

My self compiled cdrecord reports about my burner holding a CD-RW :

  $ cdrecord -v dev=0,0,0 -atip
  Cdrecord-Clone 2.01.01a04 (i686-pc-linux-gnu) Copyright (C) 1995-2006 Jörg 
Schilling
  ...
  Vendor_info: 'HL-DT-ST'
  Identifikation : 'DVDRAM GSA-4082B'
  ...
  Current: 0x000A
  ...
  Profile: 0x0009
  Profile: 0x000A (current)
  Profile: 0x0008 (current)
  Profile: 0x0002

whereas the ProDVD binary reports for the same situation

  $ /usr/bin/cdrecord-prodvd.sh -v dev=0,0,0 -atip
  Cdrecord-ProDVD-Clone 2.01.01b03 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling
  ...
  Current: CD-RW
  ...
  Profile: CD-R
  Profile: CD-RW (current)
  Profile: CD-ROM (current)
  Profile: Removable Disk 

Google makes me believe that the hex values are drive independend:
  http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/cdrw/mmc.c
  Function print_profile_name()   
So probably one should count 
  Current: 0x000A 
as alias of 
  Current: CD-RW


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to tell if mounted media is CD-R, CD-RW or CD-ROM?

[scdbackup]

Hi,

> > Looks like Joerg is not amused by some bug-or-feature of
> > your Linux.
> 
> Take out the "your" part :-)

Ok. Neither mine nor yours.


> I made all tests with stock 2.4.32 kernel.org kernel.
> Now I booted the latest RHEL3 (2.4 based) kernel and it has the very same 
> issue.
> With kernel 2.6.15.4 it does work, that is it prints "is erasable",
> even if before the string
> "ATIP info from disk"
> I get 100 lines from cdrecord with
> resid: 61752
> ...
> the number 61752 is always the same.
>
> So it seems this is a problem with kernel < 2.6.

I use a (more or less vanilla) SuSE 9.0 with kernel 2.4.21.
No such problems with self compiled
  Cdrecord-Clone 2.01.01a04 (i686-pc-linux-gnu) Copyright (C) 1995-2006 Jörg 
Schilling
or binary downloaded
  Cdrecord-ProDVD-Clone 2.01.01b03 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling


The fact that two different writers on different busses
show the same illness indicates that there is some
central problem with that particular computer system.
A bad kernel version is quite improbable by now.
Does the system show any other glitches ?


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to tell if mounted media is CD-R, CD-RW or CD-ROM?

[scdbackup]

Hi,
 
> While going through the changelog of the shell script we're using I
> found a note of one of my colleagues which said that in the past (when
> we used plain IDE CD_RW drives) we got this problem occasionally. I
> thought it was a fluke and promptly changed it back to be strict (the
> shell script had been modified to "suppose" it to be a CD-RW if no
> "erasable" script was found ) and got burned the next day with an  LG
> GSA-2164D (USB DVD writer)  with a CD-RW inside.

Strange. You don't torture your media in a peculiar way,
i suppose.

> Note the "Linux bus mapping botch message"
> ./cdrecord-prodvd-2.01.01: Warning Linux Bus mapping botch.

Qu'est-ce que c'est "botch" ? Aha. "Pfusch", "Stuemperei".
Looks like Joerg is not amused by some bug-or-feature of
your Linux.


> ./cdrecord-prodvd-2.01.01: Input/output error. read buffer: scsi sendcmd: no 
> err
> or
> CDB:  3C 00 00 00 00 00 00 FC 00 00
> status: 0x0 (GOOD STATUS)
> cmd finished after 0.002s timeout 40s

The self-contradicting message texts indicate that cdrecord
is faced with failures which are not accompanied by some
recognizable error codes.
Wether this is related to the "botch" remains open.

Is this behavior bound to a certain kernel version ?
Can you afford to boot some rescue Linux or Life-CD
with a different kernel to see wether this behavior
persists ? 
(For a x86 PC you could use 
  http://www.tux.org/pub/people/kent-robotti/looplinux/rip
which already contains a cdrecord.)

 
> I can burn the CD-RW succesfully with cdrecord.

This could mean that only the -atip related activities
of cdrecord are in trouble on your system.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to tell if mounted media is CD-R, CD-RW or CD-ROM?

[scdbackup]

Hi,

> However, recently I found that in some cases cdrecord, maybe due to the
> drive not returning all the info it needs, will not print the "erasable"
> string even if the media is CD-RW (cdrecord can succesfully burn it).

Oops. My own backup tool relies on that same output of
cdrecord -atip  and up to now i had no misleading output
with CD-RW. Nor do i have such reports from users of my
tool.

Can you specify the circumstances under which this happens ?
Is this result reproducible with the same individual media ?


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mkisofs gives 'file too large for defined data type' error on 4.3GB file

[scdbackup]

Hi,

> > I do not know wether tar needs a neat EOF from the media
> > [...]
> 
> Actually, if reading from a named pipe instead of the device, it works OK. 
> Then just put in disc 1, 'cat /dev/dvdrw > named-pipe', and on another 
> terminal 'tar -t -f /named-pipe --multi-volume'.  When the output ends from 
> the cat command, tar asks for the next volume, so the next disc goes in and 
> cat sends the disc data to the pipe to continue the multi-volume archive!  It 
> works pretty good!

This astounds me a bit.
Whatever, if it does work for you and stands all
your tests: Congrats.


To my own experience the CD-ROM drivers of Linux return
a more or less arbitrary number of extra bytes at the
end of the media. Not much, but still enough to spoil
a neat seamless volume change.
With afio or uncompressed tar the reading archiver might
get back on track after a few extra kB. With gzipped tar
you will not get happy any more afterwards.

With DVR[+-]RW it is even worse since most read drivers
return a substantial amount of extra bytes. Usually up to
the highest byte count that was ever written to that media.
Sometimes even up to the full (unwritten) capacity of the
media.


> I'm getting tar to output to a named pipe.  I just do a 'growisofs -Z 
> /dev/dvdrw=/bak/dvd-bak.pipe' and it works fine.  when tar asks for the next 
> 'tape', I just put in a new disk and execute the same command and it works
> great.

Can it be you rely on growisofs not to read more bytes
from the pipe than it can write to the media ? Given
the new ring buffer in 6.0, i would say this is a
daring assumption.

man tar is so sparse ... google ...
http://www.gnu.org/software/tar/manual/tar.html#Using-Multiple-Tapes
Aha, there is a companion for --multi-volume named
--tape-length= .
That might be a cleaner way to deal with the problem.
Did you already use that option ?

I read there:
"Each volume of a multi-volume archive is an independent tar
 archive, complete in itself."
That might explain why you have no problems with the 
extra bytes when reading.

So i believe it is not like:
> When the output ends from
> the cat command, tar asks for the next volume,
but rather that tar ends reading the volume after
encountering its volume/archive end mark and opens
a new communication channel via the named pipe
object for the next volume. The old cat command then
probably dies from broken pipe.

Nevertheless, a nice stunt.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-reply:<[EMAIL PROTECTED]>

[scdbackup]

Hi,

> How can I write a single file to a DVD+R(W)? I tried to use
> mkisofs's -stream-media-size 2291000 option

Are you sure to have tried the example from man mkisofs
properly ? (Replacing the star command by appropriate tar.)
  % star -c . | mkisofs -stream-media-size 333000 | \
cdrecord dev=b,t,l -dao tsize=333000s -

If so, the failure might be worth a bug report.


> Can I just do a growisofs -Z /dev/dvdrw=/tmp/dvd-bak-1.tar or something?

Yes. After all, a tar-archive can stand for itself.
I do not wrap my afio- or star-archives into an
ISO filesystem and they are nicely readable afterwards.


>  Then 
> wouild a 'tar --multi-volume -t -f /dev/dvdrw' access the archive?

Besides the --multi-volume : yes.

I do not know wether tar needs a neat EOF from the media
(which it won't get from CD or DVD in most cases) or wether
it is able to recognize the end of a multi-part on its own.

You will have problems to produce a multi-volume archive anyway
because you will surely lack of a decent end-of-tape at write
time. So better keep your archives small enough to fit on a
single media.

I know two backup projects which cater for multi-volume on
optical media.
Paul Serice's shunt:  http://www.serice.net/shunt/ 
My scdbackup   :  http://scdbackup.sourceforge.net/main_eng.html
Be advised to have a look at both projects. They offer quite
different services and results.

scdbackup uses afio or star format but can be talked into
using tar, too.  For your purposes the following would be
one of several possible solutions:
  tar czf - ... | sdvdbackup -pipe_to_media -multi_volume
Ask me for support if needed.


> Also, the mailing list won't let me subscribe to it.  I've tried several 
> different addresses through the http://lists.debian.org/cdwrite/ page, and 
> nothing happens.

That page was already broken when i subscribed a few years ago.
Obviously it is a kind of initiating ritual to get fooled by it.
>From the headers of the list mail:

List-Id: 
List-Post: <mailto:cdwrite@other.debian.org>
List-Help: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <mailto:[EMAIL PROTECTED]>
List-Unsubscribe: <mailto:[EMAIL PROTECTED]>

So you are supposed to mail subject "subscribe" to 
[EMAIL PROTECTED]


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: growisofs did not exit cleanly :P

[scdbackup]

Hi,

> Denis S. wrote:
> Subject: growisofs did not exit cleanly :P
> 
> Recently I've upgraded to new dvd+rw-tools and got new error which 
> appear each time k3b finish writing DVD, because of this error K3B is 
> unable to perform verification of written data,

> Here is error message:
> growisofs

Actually mkisofs speaking here:
>0.09% done, estimate finish Fri Feb 17 19:44:01 2006

This is from growisofs:
> /dev/hdc: "Current Write Speed" is 4.1x1385KBps.

mkisofs did finish successfully:
> 542225 extents written (1059 MB)

Now growisofs tries to finish.
> /dev/hdc: flushing cache
> /dev/hdc: updating RMA
> /dev/hdc: closing session

No error message to spot, though.

I guess you get above "growisofs did not exit cleanly :P"
from K3b. Probably K3b really got a non zero exit value
from growisofs indicating that something went wrong.


> -use-the-force-luke=notray 

For this option i am too much a coward.
Andy was so kind to implement ...=noload .
Nevertheless this should not be a reason for a non-zero exit.


Given your previous problems with K3b+growisofs this might
be related to burner+media. But usually growisofs should
issue some kind of error message with a little frown in
such a case.

I assume that K3b tried to make rewritable your media via 
  dvd+rw-format -blank=full /dev/hdc
and failed. cdrecord-ProDVD obviously did not fail but possibly
the media are still not good for growisofs.

Two things could be tried:

  dvd+rw-format -force /dev/hdc
to achieve DVD-RW mode "Restricted Overwrite" which will avoid
the need to blank or format the media before re-use by growisofs.
Then try K3b+growisofs again with that media.
(If you blank the media by cdrecord-ProDVD you get back into
 a state that demands blanking before re-use. If you format it
 by  dvd+rw-format -blank=full /dev/hdc you will also get back
 to the state which is only writeable once and then needs
 -blank=full again. You always need to blank before re-using 
 DVD-RW with cdrecord-ProDVD.)

  mkisofs ... | cdrecord-ProDVD ...
You will have to study man mkisofs and man cdrecord, or read
one of the many CD/DVD burning tutorials, or get a frontend to
cdrecord-ProDVD for that.
I can offer a non-GUI frontend which is about as hard to use
as commands ls or cp. One has to do some initial setup, though.
Contact me, if you are interested. It can use both, growisofs
and cdrecord-ProDVD.

As Andy states on growisofs' webpage, cdrecord-ProDVD uses
a burn method which is different from the two methods of
growisofs. So it might be worth a try.

 
Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "logical unit communication failure" c2scan NEC ND-4550A 1.07

[scdbackup]

Hi,

> > > > I wrote:
> > > > I am looking since quite a while for the particular
> > > > and substantial security problems which one is said
> > > > to have if one allows w-access to a CD/DVD writer.
> > I understand this puts my 60 Euro burner at risk
 
> Joerg Schilling wrote:
> THe bug in the linux kernel was to allow _any_ commands even if only
> _read_ access was present.

This is frightening in general and somewhat appeasing
in my special problem. (By telling me that not w-perms
was the problem which had to be tackled in a hurry.)

I understood from some of your statements in the past that you
expect severe security problems if any user is able to write
to the CD/DVD burner.
Obviously you have chosen the workloaden way of programming
an automated superuser who cannot be fooled by the user.
As said i trust your ability to fight off the vast majority
of smart fools. (We should not forget Goedel's Incompleteness
and the related Halting Problem when betting on wise automats.)

For cdrskin, nevertheless, i would prefer to go the cheap way:
The sysadmin is responsible for who has permission to use
the burner and people can use cdrskin only for burning CD and
killing the burner - but not for attacking system integrity. 

If there are known tricks to escalate w-permission on /dev/hdc
to some more extended privileges (e.g. w-perm on all /dev/hdX)
- then i would have to consider a setuid approach.
I also would have to reconsider my way of using growisofs.


Up to now, i have learnt some interesting pitfalls and augmented
the documentation of scdbackup by an advice to mount -o nosuid,nodev.
To my luck there was no hard reason, yet, to decide for programming
a setuid-safe application.
You would spoil my day by naming such a reason, Joerg. But on the
long run i would surely have to be thankful for that.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "logical unit communication failure" c2scan NEC ND-4550A 1.07

[scdbackup]

Hi,

> > I wrote:
> > I am looking since quite a while for the particular
> > and substantial security problems which one is said
> > to have if one allows w-access to a CD/DVD writer.
> Matthias Andree wrote: 
> As far as I understand Jörg, vendor-specific commands are often involved
> in CD writing, and if they are filtered out, CD writing may not work
> with certain devices -- this is the central point of his criticism.

I understand this puts my 60 Euro burner at risk
if i allow w-access. (It is also at risk if i allow
physical access with a few drops of Loctite.)


> >   Is system security in general threatened by the extreme
> >   example
> > chmod a+rw /dev/hdc   (resp.  /dev/sg0 with 2.4 ide-scsi)
> 
> That depends if users can obtain device nodes or setuid privileges by
> mounting media from this drive.

Uhum. Valuable keywords to learn from. Thanks.
(Also a confirmation that i am not really fit for a
 foolsafe setuid/sudo program, yet.)


The setuid privileges demand w-rights ?
I mean, that is an interesting sneak, but isn't it rather
related to   mount -o user,exec,suid  ?

man 8 mount: option nosuid warns of suidperl(1).
(Who installed that crap on my computer ? 
 Not setuid, but it is there. Off with it !)


Device nodes ... uh oh ... do you mean this :
a mknod, a chmod with lax permissions, burned to CD,
CD mounted, cat /dev/zero > /cdrom/my_dev_hda_backdoor

Is this possible ? Looks much like a mount problem too.
(mount -o dev ... but i must learn more. Ay caramba.)


> Judging from the system security, setuid/sudo is always dangerous;
> injecting ANY code into cdrecord would allow every user a root shell.

w-permission to setuid-cdrecord should be restricted to
root, of course.
Since years, i trust Joerg's ability to defend that setuid
situation. Wether the trust is really justified or not, 
cdrecord never did any evil things to me. So for now, it's ok.

> > [nice opportunity of own text recycling:]
> >   I have to amend that i am experienced but not in the sense
> >   as Joerg or kernel programmers. I know my limits and am not
> >   100% sure wether i could make a program that is setuid-safe.
> 
> That depends on the overall setup. If the setuid program does some
> privileged operations and can then drop all of its privileges by means
> of setuid() early, it's not very difficult.

I will have to talk to the libburn people about the
appropriate moment to drop privileges. The longer the
time window, the more uncomfortable i would feel.

Thanks for the advice.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "logical unit communication failure" c2scan NEC ND-4550A 1.07

[scdbackup]

Hi,

> This was not a change made because it would be nice, it was made because 
> it became public information that anyone who could burn could change the 
> firmware. Security fixes sometime do have to be done quickly, evil 
> people do tend to jump on any opening in the time between a 
> vulnerability becoming public and being fixed.

I am looking since quite a while for the particular
and substantial security problems which one is said
to have if one allows w-access to a CD/DVD writer.

By help of your name and some keywords from above i
googled into a thread at the kernel mailing list.
Nevertheless the threads and subtreads in the archives
are a bit manifold ... sigh.

Could you please answer me the following questions
resp. point me to some comprehensive answers :

- Is there other stuff at risk besides my 60 Euro burner ?
  Is system security in general threatened by the extreme
  example
chmod a+rw /dev/hdc   (resp.  /dev/sg0 with 2.4 ide-scsi)

- What was the worst threat which could be identified
  through that discussion ? 

- If i am willing to risk my burner's health (which i do
  with any physical tray load, actually) what would you
  advise me to do:
  - run a self written setuid-root or sudo program on restrictive
rights
  - allow generous access to /dev/hdc and use neither setuid
nor sudo
  I have to amend that i am experienced but not in the sense
  as Joerg or kernel programmers. I know my limits and am not
  100% sure wether i could make a program that is setuid-safe.
  Nevertheless if chmod a+w is globally deadly, then i will 
  hardly have a choice but to try.
 
This topic affects users of growisofs too, i guess.
At least i run my growisofs that style. (No hostile
users expected ... but one never knoes.)

Thanks in advance for any information.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdwrite@other.debian.org

[scdbackup]

Hi,
 
> My purpose using RockRidge is retaining oringal ownership and
> permission of data to solve following problem;
> 
> I burnt /home/ of a FC3 box on CDs. /home/ was on its own partition.
> Then running LFS LiveCD I copied the CDs on a partition of a new HD
> [...] Later I discovered all data after
> transferred from the CDs onto the partitions became "read only" and
> permission changed from User to Root. Now I need to reinstate their
> original state, i.e. Write/Read, User, etc.

Not knowing the particular capabilities of your mkisofs version
and of your ISO filesystem driver, i would generally state that
a plain ISO tree is not the best candidate for exact 1:1 
data backup or transport. (It is my favorite for user data
backup, though, if ownership and permissions are trivial.)

mkzftree ... that's new to me ... it seems to add another
level of complexity. I would only employ such a thing if
the other open issues are settled.

With my own backup tool i advise to use afio or star format if
ownership or permissions are essential or other file types than
plain, dir or softlink are to be backuped.
mkisofs -R  does record more file attributes and therefore might
be usable with other than just the above filetypes but i would
not trust it to record really everything. Especially since you
have to cope with the possible peculiarities of the ISO
filesystem driver when reading the data.

My favorites for recording everything (but not a whole partition)
are currently :
  find | afio -o  (or  afio -oZ , rather than afio -o | gzip)
resp.
  star -c -xdev -acl -link-dirs -dump 
Maybe Joerg can propose an even better star command for your  
purpose.

One may compress the output, one may encrypt it, and one may
pipe it into cdrecord
  | cdrecord ... -
or growisofs
  | growisofs ... -Z /dev/dvd=/dev/fd/0
like one would have done with an ISO image.

To be read directly from unmounted media like from a tape device
  afio -tv /dev/cdrom
resp.
  star tvzf /dev/cdrom

You may do this with any trustworthy archiver, of course.
Not only with afio or star.

You may also direct the archiver output into a hard disk
file and use your usual burn program to put that file on
media. Then you would have to unpack it from *mounted* 
media by something like 
  afio -tv /mnt/my_archive_file.afioz

And of course, the content info options "t" have to be
replaced by the unpack options of the archivers "i" resp. "x".


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,

>>> You've merely heard an echo of quasi-technical rumor.
>> 
>> I repeated (my understanding of) the guts of what was said, I don't say
>> it's technically correct.
>
> Please note that I rather reacted on Thomas' interpretation of the 
> statement/rumor you've passed on
> He interpreted it as if there 
> is something magical "DVD-patched cdrecord" does, which provides 
> ubiquitous *technical* justification for its existence. I just couldn't 
> let him keep believing it, that's all:-)

That's how i perceived it and that's about what i was asking
for an echo by the usual experts.
I appreciated the clarification. Thanks.


About my negligent spreading of the rumor that 
Restricted Overwrite was a growisofs attribute:

I googled for "restricted overwrite". The results on the
first page are as follows:

1) a german page refering to Andy Polyakov
2) a japanese (?) page refering to dvd+rw-tools
3) a general DVD explanation on www.roxio.com
4) a question from this mailinglist about dvd+rw-tools
5) a german university talking about growisofs
6) a dutch university talking about dvd+rw-tools
7) http://fy.chalmers.se/~appro/linux/DVD+RW/-RW/
8) a german general explanation of DVD technologies

So as far as Google voting is concerned, a 75% majority
points to Andy Polyakov as foster father of Restricted Overwrite.
At least if queried via a german Linux Mozilla.

No doubt that this will cause confusion among future
archeologists.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,

> > I am not aware of computer DVD-ROM drives which refuse
> > to read successfully verified DVD+RW
> 
> Well, my DVD-ROM cannot read any of the DVD-R or DVD+RW disks that I 
> have tried.

That would be 1 point for the "+" team and 1 for the "-" team.


> I use TDK and Verbatim media written with a Plextor PX-716UF drive using 
> cdrecord-ProDVD.

I have some TDK DVD+RW, too.


> The kernel identifies the drive as: LG DVD-ROM DRN-8080B, ATAPI CD/DVD-ROM

And i thought that LG was good with +RW.
It is all so unpredictable !


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,

> >   Vendor_info: 'HL-DT-ST'
> >   Identifikation : 'DVDRAM GSA-4082B'
> >   Revision   : 'A201'
> 
> I am not sure about the firmware/laser pule former quality of this 
> Hitachi Goldstar drive. I recommend to repeat this test with
> a drive from Pioneer, Plextor or NEC
> >
> > 30 minutes later it is finished without further message.
> > The burn attempt via cdrecord-ProDVD fails, nevertheless:
> 
> SO the drive did show no problems for the second blank=full operation

I will keep the media for my next burner to come. :))


> >   :-[ PERFORM OPC failed with SK=3h/ASC=73h/ACQ=03h]: Input/output error
> 
> If you use a program with user unfriendly output, please look up the error 
> code
> and expand to text.

Of course i got a copy of
  http://fy.chalmers.se/~appro/linux/DVD+RW/keys.txt

The errors are listed and say the same as the cleartext
messages of growisofs. Namley that OPC failed and that
there occured a write error.


> The biggest difference between DVD- and DVD+ is that
> all DVD- manufacturers are forced to pay for an independent test institute
> that does frequent round robin tests. Any problem is flagged to the related 
> manufacturers of failing pairings.

At least for me and my drive the efforts to bribe away
the gremlins have not paid off.

But i can live with that for a while.
Thanks for the advice about -force. I will keep that in
mind for similar occasions.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,

> > This is the first time i read about a technical reason for those
> > patches. I always thought it was to keep alive a source-open GPL'd
> > version of cdrecord which is able to burn DVD.
> 
> I don't understand what you like to say here

It is not easy to discuss the cdrecord-ProDVD topic in any
language. Thus i prefer to stay quite neutral.

Up to the last few days i thought that the issues around
cdrecord and DVD were legal and interpersonal ones. Now i
learned that there are a few other things involved.
I will learn further, probably.


> > I wonder wether Andy and Joerg are aware of a need for such
> > extra treatment. (Listening for an echo now ...)
> 
> ??

Ok. You both don't see any technical truth in the rumor
spread by the person who tried to bite off Volker's
head. Nobody else stood up. File closed.


> > My -RWs leave me after a few months but that does not look
> > like a subtle format problem. Rather like the dye changing
> > its photochemical properties within a year after production.
> 
> This is most likely caused by OPC problems in your writer.
> Try cdrecord -force blank=full

Hm ... i tried much, but i never tried -force.

blank=full ? My  Cdrecord-ProDVD-Clone 2.01b31  does not
know "full". It's about time i try the new 2.01.01b03 ...
... nope ... no blank=full ...
Let me try it with "all" :

  $ /usr/bin/cdrecord-prodvd.sh dev=0,0,0 -force blank=all
  Cdrecord-ProDVD-Clone 2.01.01b03 (i686-pc-linux-gnu) Copyright (C) 1995-2006 
Jörg Schilling
  Unlocked features: ProDVD Clone 
  Limited  features: 
  This copy of cdrecord is licensed for: 
private/research/educational_non-commercial_use
  scsidev: '0,0,0'
  scsibus: 0 target: 0 lun: 0
  Linux sg driver version: 3.1.25
  Using libscg version 'schily-0.8'.
  Device type: Removable CD-ROM
  Version: 0
  Response Format: 2
  Capabilities   : 
  Vendor_info: 'HL-DT-ST'
  Identifikation : 'DVDRAM GSA-4082B'
  Revision   : 'A201'
  Device seems to be: Generic mmc2 DVD-R/DVD-RW.
  Using generic SCSI-3/mmc-2 DVD-R/DVD-RW driver (mmc_dvd).
  Driver flags   : DVD MMC-3 SWABAUDIO BURNFREE 
  Supported modes: PACKET SAO  WARNING: Phys disk size 65264 differs from rzone 
size 0! Prerecorded disk?
  WARNING: Phys start: 196608 Phys end 261871
  Waiting for drive to calm down.
  Starting to write CD/DVD at speed 2 in real force BLANK mode for single 
session.
  Last chance to quit, starting real write0 seconds. Operation starts.
  cdrecord-ProDVD: Input/output error. blank unit: scsi sendcmd: no error
  CDB:  A1 00 00 00 00 00 00 00 00 00 00 00
  status: 0x2 (CHECK CONDITION)
  Sense Bytes: 70 00 03 00 00 00 00 10 32 4D 03 0D 0C 00 00 00
  Sense Key: 0x3 Medium Error, Segment 0
  Sense Code: 0x0C Qual 0x00 (write error) Fru 0x0
  Sense flags: Blk 0 (not valid) 
  cmd finished after 6.591s timeout 9600s
  Starting to write CD/DVD at speed 2 in real force BLANK mode for single 
session.
  No chance to quit anymore. Operation starts.

30 minutes later it is finished without further message.
The burn attempt via cdrecord-ProDVD fails, nevertheless:

  ...
  BURN-Free is ON.
  Starting new track at sector: 0
  Track 01:0 of 4480 MB written.cdrecord-ProDVD: Input/output error. 
write_g1: scsi sendcmd: no error
  CDB:  2A 00 00 00 00 00 00 00 1F 00
  status: 0x2 (CHECK CONDITION)
  Sense Bytes: 70 00 03 00 00 00 00 10 32 4D 03 0D 0C 00 00 00
  Sense Key: 0x3 Medium Error, Segment 0
  Sense Code: 0x0C Qual 0x00 (write error) Fru 0x0
  Sense flags: Blk 0 (not valid) 
  cmd finished after 11.053s timeout 100s
  
  write track data: error after 0 bytes
  cdrecord-ProDVD: A write error occured.
  cdrecord-ProDVD: Please properly read the error message above.
  cdrecord-ProDVD: Input/output error. test unit ready: scsi sendcmd: no error
  CDB:  00 00 00 00 00 00
  status: 0x2 (CHECK CONDITION)
  Sense Bytes: 71 00 03 00 00 00 00 10 32 4D 03 0D 0C 00 00 00
  Sense Key: 0x3 Medium Error, deferred error, Segment 0
  Sense Code: 0x0C Qual 0x00 (write error) Fru 0x0
  Sense flags: Blk 0 (not valid) 

  
At least with this burner, no blanking or formatting treatment
via cdrecord-ProDVD or growisofs did ever help after the
media went bad. 

I -force blanked another media by cdrecord-ProDVD and could
dvd+rw-format it to Restricted Overwrite afterwards.
Nevertheless, growisofs aborted on OPC:
  :-[ PERFORM OPC failed with SK=3h/ASC=73h/ACQ=03h]: Input/output error

I also tried the new growisofs option which avoids OPC.
No success:
  :-[ [EMAIL PROTECTED] failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error
  :-( write failed: Input/output error


> I cannot recommend DVD+RW because the interchange compatibility 
> is too low.
[from the reply to Volker]:
> And BTW: the problems I did see with DVD+RW media while trying to read 
> the same test media (written on different drives) on different drives
> clearly shows that DVD+RW compatibility is lousy. This is why I prefer DVD-RW.
> DVD-RW did never cause real trouble.

I am not aware of 

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,
 
> > But why did the [DVD-RW] media work in september 2004 and die a quick
> > and reliable dead in november 2005 ? The same spindles. Two
> > brands with two different media infos. Wether unused previously
> > or re-written.
> 
>  You'd need a useful error rate scan of the media to establish
> this. 

Some lower level ECC mechanisms ?
[sarkasm mode on]
Are there still any error checks left and used with DVD ?
[sarksam mode off]

To my experience (SuSE 9.0, two reader drives), DVD read errors are
not rejected at the drive+driver level but the false data are
happily forwarded to the user process without any error indication.
With CD-RW this is not the case. If a CD-RW fails to verify, then
this is always accompanied by a system error message or at least
an early end of the data stream (experienced with SuSE 6.4 to 9.0).


I use a checksum list which covers 64 kB blocks of the media.
In most cases of DVD-RW failure, it was not applicable, though,
because the media flatly refused to take any data. The checksums
of the previous content still verified, then.

The block checksums were introduced to find out about the
characteristics of young DVD-RW failure. But they are more 
useful in evaluating the rare verify problems with DVD+RW 
media. 
It turned out that if a DVD+RW does not verify a particular 
64 kB block on the first try then it usually does it on
the second try or (in two cases) shows a wandering block
error. (Each try is a sequential read of the whole media,
not an immediate retry of the failed block.)

The checksum lists would give me a good chance to recover
from volatile block errors but i do reburn those rare glitches,
rather than putting them on the shelf. 


> * Your drive is in fact defective. At first, error correction ...
> 
>   No-one else reporting this kind of problem lends weight to this being
>   the case.

I will learn when this one has passed the way and the next one
gets built in. Currently it works flawless with DVD+RW und CD-RW.
Shrug.
Maybe i should buy some new DVD-RW and test them ... but i am not
eager to pay good money for potentially not-so-well-working media.
Maybe i should buy a new burner ... but that would reward the
industry for selling poorly tested hardware.
Shrug again. Let's burn a little backup for relaxation ... :))


> * Your drive has deteriorated, put sloppily, is worn now. How many DVDs
> did you burn in it in its lifetime?  Give us a number.

769. (No pun. They get logged.)


> friend of mine established for a CD burner that its life lasts 300-400
> burns, then it's become so slack, it doesn't meet quality control any
> more.

Obviously i have more luck with burner longevity.

Since january 2003 there were 2109 CDs. Mostly -RW.
The LG DVD burner did about 700 of them (since summer
2004). 
No signs of weakness with CD-RW or CD-R. 

The LITE-ON CD-RW which did the previous 1400 CDs is
still working fine, too.


> * The media you tried is of short-lived quality.

At least that special combination of burner and media
seems to be.
I came to the decision that they just don't like each other
and that this relationship got a bit deeper over the time.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,

> > This is the first time i read about a technical reason for those
> > patches.
> 
> You've merely heard an echo of quasi-technical rumor.

For me as an application programmer all talk about system,
firmware or hardware is rumor. One learns to live with that.


> > My -RWs leave me after a few months but that does not look
> > like a subtle format problem. Rather like the dye changing
> > its photochemical properties within a year after production.
> 
> It might as well indicate your particular firmware deficiency: it simply 
> fails to pick optimal power for particular media manufacturer[s] or 
> DVD-RW media in general.

Well possible.
But why did the media work in september 2004 and die a quick
and reliable dead in november 2005 ? The same spindles. Two
brands with two different media infos. Wether unused previously
or re-written. I made exact lab logs in 2004 because those are
donated media and i wanted to use them for proper science.
They were not flawless but most of them worked. Now they are
mostly trash.
Either my burner goes bad (and there is no indication with DVD+RW
or CD-RW), or the media went bad at normal room temperatures,
or both.


> In other words I find it hard to believe it's inherent -RW 
> problem and I bet that a whole lot of people would refute your 
> experience.

One remarkable point with DVD+RW media is that all brands
of 4x media which i ever bought are reported as
 Media ID:  RICOHJPN/W11
whereas three DVD-RW brands yielded three media ids.

What, for example, shall i think of a warning sticker on 
the wrapper of TDK DVD-RW media labeled as "2x" 
  "WARNING
   This product is intended for use only in 4X speed
   DVD-R/RW drives/recorders."
and further in small letters on the backside:
  "Use of this product in certain [...] DVD-RW drives [...]
   may result in damage to both the loaded disc and
   to the drive [...] the lense [...] becomes fogged [...]
   source of the problem is a firmware bug [...]"
No list of endangered drives, of course.
(Calm down, Thomas, don't be unrelaxed ... om mani padme hum ...)

The variety of cooks seems not to be conducive to the
DVD-RW broth. Let me hope the RICOH DVD+RW production plant
never burns down.

This is my impression as user and as provider of support to
other users. I got no insight into the commercial or technical
reasons of that mess.

If i get asked about what burner to buy, i answer that i got
good experiences with my current one and DVD+RW. Of course i
do not state that -RW and other brands would not work.
I do state, though, that DVD burning is by far not as technically
mature as is CD burning. A matching combination of drive and
media is still a prescious thing.


> > The loss rate is reduced if they are in growisofs state "restricted
> > overwrite"
> 
> On a side note, phrases like this last one is like soil for 
> quasi-technical rumors and other controversies.

That was not my intention.

> There is no such thing as "growisofs state "restricted overwrite""!

My apologies. Meant was:

  if they are in the state which the documentation of dvd+rw-tools
  refers as "restricted overwrite" but which is not mentioned or
  used by cdrecord-ProDVD.

It is simply that growisofs is the only program known to
me that allows this burning procedure which resembles +RW 
and obviously not only saves the time to blank but also
seems to save the life of my remaining DVD-RW media.

My original sentence might be a daring shortcut but is it
really misleading from the viewpoint of users ?


> But please, don't mix 
> together applications and recording modes in terminology.

To my defense i ask you to consider that the specs of
the standard bodies are not easy to obtain and not easy
to understand.
Furthermore i promise to be more exacting. On the risk
that my mails get even longer.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,

> > informing you in advance about my upcoming cdrecord
> > compatibility wrapper around libburn: cdrskin .
> 
> What kind of advantage should this have?
> 
> Cdrecord is opensource and portable to 30 different platforms.
> 
> Why do you spend time on this?

The fundamental motivation is as always, of course:
Curiosity, dark and stormy nights, the will not to give up
on the first serious obstacle, the pride to see it working, ...

Plus, there is the need to give scdbackup development a rest
before the upcoming next stable release. :))


> What problem does it solve that cannot be solved by cdrecord?

It is because of a long term strategic consideration.
My backup tool can make use of three different formatters
and three different burn facilities. In both categories, 
two of three are made by you: mkisofs, star, cdrecord for CD,
cdrecord for DVD.

With CD backups i did not have any alternative. Up to cdrskin
there was only one processing chain where your software was
not crucial (namely DVD via afio + growisofs).

Such a monoculture is unhealthy. We all are not immortal
and we all are prone to changes in our personal interests.
One reason why i made a new google survey on CD writing in
december was that troll who nearly let you pop a heart valve.
(Don't get me wrong, but sometimes you are very unrelaxed.)


Since quite a while i was looking for some way to write CDs 
without using cdrecord and without patching a Linux kernel.
(Actually i would have expected a simple CD burn device driver
to become part of the Linux system some day. But i am still
waiting for a thing like that.)

Whatever, a few weeks ago i discovered that there is libburn
waiting for applications since february 2004. I began to explore
its capabilities and limitations and managed to overcome two
obstacles which would make it unsuitable for my own backup tool.

cdrskin has become a useable program for data recording on CD
meanwhile.
As long as i do not write small amounts of data via a stdin pipe 
the performance is comparable to cdrecord. (The lack of TAO makes
it necessary to announce generous track sizes in advance and to
pad up the CD content. The same usability problem is present with 
cdrecord-ProDVD when writing DVD. Not with growisofs, though.)


Joerg, i do not try to convince you that cdrskin is any better
than cdrecord. I do not even try to convince myself although
it has some loveable detail features in comparison to cdrecord.

It would have been a waste to let libburn lying around in the
web with a quite unknown GUI frontend and a few rather exotic
language bindings.
At least now it is ready for evaluation tests via cdrskin.
You can submit it to K3b and it burns a data project.
For my backup tool it provides a lean burner binary. I consider
to prepare an extra lean version with reduced compatibility and
feature set.

Maybe some interested people help to add missing features and
maybe it will open a path to get rid of the quarrel around
patched cdrecord.
  http://scdbackup.sourceforge.net/cdrskin_eng.html


See the positive aspect, Joerg. This time it is not a fork
but an emulation.
It is meant neither hostile nor obtrusive.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi Joerg,

> > Would there be volunteer testers for a united cdrecord
> > compatibility wrapper based on libburn for CD and
> > growisofs for DVD ? 
> 
> The last time I checked libburn, it was a complete desater.
> The first time where a project turned unmaintainable short
> after it's creation.

It's not all that bad, currently. :))


Let me take the occasion to show to you the due politeness and 
respect by informing you in advance about my upcoming cdrecord
compatibility wrapper around libburn: cdrskin .

It is not much announced yet because it still depends on a
slightly patched libburn. I am negotiating with Derek Foreman
about how to include the patches into his code.
... google ... it already begins to sprout. (What is a Gentoo ebuild ?)

I took some effort to make clear that cdrskin is not cdrecord.
("Do not bother Joerg Schilling" et al.)
It has to issue some cdrecord-like text messages though, in
order to be compatible enough to serve the cdrecord frontends.
The documentation is supposed to make clear that these are
quotations from your work and the standards which you did set.

A problem is that the frontends want to see some words
like "Cdrecord" and "Copyright" in order to recognize a
program as cdrecord compatible. So i have to issue something like
  cdrskin 0.1.1 : limited cdrecord compatibility wrapper for libburn
  Cdrecord 2.01-Emulation Copyright (C) 2006, see libburn + cdrskin

After K3b made from this line out of cdrskin's first -version text
  "Cdrecord-Emulation 2.01 Copyright (C) 2006 Thomas Schmitt"
the following text line 
  "Using cdrecord 2.1 - Copyright 2006 Thomas Schmitt"
i even removed my name from that -version text to avoid any further
embarrassing frontend postprocessing. Now K3b can only versify:
  "Using cdrecord 2.1-Emulation - Copyright (C) 2006, see libburn + cdrskin"
which is clear enough, i hope. 

Give me a note if you see any undue ambiguity remaining.


> > Isn't there anybody in the world who did not make his own fifo ? :o)
> 
> I did since 1987 

I use that one since 1997. It saved me from lots of misburns.


> Be careful, most "pthreads" programs that have been developed on Linux
> do not run elsewhere because Linux is not very standard compliant.

In this special case it is only to cope with the threads
initiated by libburn. So Linux-centricicsm would be ok,
for once.


> If you are looking for a general purpuse fifo code, check the fifo
> code from star. It is extremely mature (as it is" on" by default 
> since 15 years) and it is higly portable.

It never let me down and it surely is optimized for effectivity.

But i have to flange my fifo at the input of libburn and
may not insert it between the reader function and the writer
function. Additionally i believe three threads are enough. So
i want to keep the fifo entirely within the supervisor thread.
This becomes a little demanding for handling multiple tracks.

The fifo has to handle several pairs of input-output channels
sequentially. When track #1 closes it has to begin to buffer
track #2 while it continues writing #1. Later it has to close
the outlet of #1 and open the outlet of #2. So libburn believes
these are two separate files on disk.
To test this whole complicated setup i made the fifo handler able
to serve several fifo objects simultaneaously (select(2) is one
of the bestest calls ever). So one fifo can play libburn + burner
and the other fifo plays cdrskin + itself. Single threaded.
Much better debuggable than the real run with libburn.

The transaction size is only 2 kB so it does not block on
writing into the pipes which are read as 2 kB blocks by
libburn.
This all is not very economizing on CPU - but CPU seems not
to be the bottleneck with system throughput currently.


I mainly miss an opportunity to write a stream of 
unannounced length into stdin like with cdrecord -tao .
For any other of my personal demands cdrskin is sufficient
now. I use it for my CD backups since about six weeks.

Audio will become quite a challenge, i guess. If ever.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,
 
> > I recently introduced a fifo into my growisofs script.
> > Now it is already obsolete. What a carreer. :))
> >
> For a talk I gave on "introduction to pthreads" I wrote a ring buffer 
> program with most of the options one could want.

Isn't there anybody in the world who did not make his own fifo ? :o)

But i could need a pointer to some programming hints about
threads and signal handling. Especially how to keep all
but a particular thread from being interrupted and jumping
into the signal handler function.


> I played with this a bit, if you are using higher level calls you can 
> replace fopen() with an open() using O_DIRECT, an fdopen() after that, 

Are you sure that the FILE functions like fread(), fwrite() don't
spoil the success ?

> The main benefit was to have less impact on 
> the rest of the system, the i/o in the program didn't run that much faster.

A less annoyed system can possibly deliver better throughput.
It is worth to further think about that. (I must get my
processing pipe leaner, first.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,

> > Bill Davidsen wrote: 
> > Because growisofs doesn't do CD, cdrecord doesn't do DVD, and -ProDVD 
> > isn't open source. I find it very nice to have a single tool to burn ISO 
> > images, because then I can write the media type fitted to the data size 
> > without needing multiple tools.
> 
> Volker Kuhlmann wrote:
> Some people I've heard like their cdrecord-style interface. My answer
> has always been "make a wrapper script", but they didn't bother
> (complaining is easier??).

Would there be volunteer testers for a united cdrecord
compatibility wrapper based on libburn for CD and
growisofs for DVD ? (With the funny property to have
TAO-like behavior for DVD and only SAO for CD. Libburn
is only available for x86 Linux 2.4 and 2.6 afaik.)

I have large parts of the necessary code lying around.
At least for data purposes, not for CD audio. It depends
much on what cdrecord options are needed. (I got an 
option logging proxy for cdrecord, too.)


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,

> > So i have not much reason to try any DVD-patched cdrecords yet.
> > I actually wonder why they live forth.
> 
> Some people appear to prefer one tool for one burning needs, without
> locking themselves in to the commercial expiring stuff.

Oh, i do not put in question the convenience to use the
burner software via a cdrecord-compatible command line
interface.
I am actually the proud originator of several cdrecord-like
wrappers around other writer software like growisofs or
libburn or the Linux kernel's devices.

I don't either dispute the inconvenience of Joerg's decision
to make the -ProDVD license as it is. If there wasn't growisofs
then i would see the license situation as a valid reason for
a GPL fork.


But up to this morning, when i read Volker's mail, i was not
aware of any technical advantage of the patched versions.
As Volker describes it, i will hardly ever make own experiments
to find out about situations where growisofs fails and one
of the patched cdrecords succeeds.
Nevertheless, i would be very interested in learning about
such situations.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,
 
> > So i have not much reason to try any DVD-patched cdrecords yet.
> > I actually wonder why they live forth.
> 
> I wondered too and questioned that, and got my head bitten off on the
> dvdrtools list

Only good we are virtual entities here.
The blood spill would be immense if we met in real life.


> A DVD+ -based burner
> has to engage some kind of emulation for DVD- media (character-based vs
> block-based), and the emulation in the burner firmware can't be trusted.

This is the first time i read about a technical reason for those
patches. I always thought it was to keep alive a source-open GPL'd
version of cdrecord which is able to burn DVD.

I wonder wether Andy and Joerg are aware of a need for such
extra treatment. (Listening for an echo now ...)


> Funny thing is though that none of the
> cdrecord dvd-patchers ever speaks up.

Besides any motivation it is not the best style to repeatedly
fork the work of somebody with whom one is in quarrel.
I am not really opposed to those versions but i confess to
have frowned on them for that style reason.


> Personally I've used growisofs for years now and it works fine, though I
> don't use -RW because +RW is just alround more convenient. No trouble
> with the -R media I burnt that I'm aware of.

My -RWs leave me after a few months but that does not look
like a subtle format problem. Rather like the dye changing
its photochemical properties within a year after production.

(The old -RWs fail on OPC with growisofs and with cdrecord-ProDVD.
The loss rate is reduced if they are in growisofs state "restricted
overwrite" and if they are rewritten frequently.
A "sequential" one that was burned and stored for a few months is
prone to death on rewrite. A virgin one, stored 14 months, 
written once in "sequential" mode, immediate attempt to re-write
... dead. I did not want to believe and killed another one.
Some media from the same spindle still serve me well for daily
backups. Even the dead ones still hold their last data in a
readable way. It is some weird burn problem. Maybe firmware
plus chemistry plus lense ageing.)


I noticed that another food discounter (named "Plus", hehe) has
entered the price fight over DVD+RW media in germany.
Seems it was a good decision to purchase my +RW loving LG drive.
These media work for me as reliable as CD-RW.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,

> > My suspicion is that this can be done by option
> >   -force
> >
> > It might be worth a try with the unpatched program.
> 
> His problems are just caused by broken DVD support in the DVD
> patch applied by Debian. 

My DVD needs get served well by original growisofs and 
cdrecord-ProDVD.
So i have not much reason to try any DVD-patched cdrecords yet.
I actually wonder why they live forth.


> Note that as this patch ignores the concept of the data structures
> used by cdrecord, it also causes CD-writing to fail under certain
> circumstances.

I meant Thaddeus' own patch to the patched program.
Obviously his patch does the same as the F_FORCE bit
and a quick research in cdrecord.c gave me the suspicion
that option -force would set that bit. To be tested by
whom it may concern.


Have a nice day :))

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dvd+rw-tools update [6.0, DVD-R DL]

[scdbackup]

Hi,

> A FIFO allows you to survive a period with low input data rates.
> If everything goes faster, you need to increase the size of the FIFO
> proportional to the size improvements.

But if *everything* goes faster, why not that period 
with low data rates too ?


> It's the absolute speed that counts.

That is the experimental result. Yes.
Now i am looking for a matching theory.

Peter's proposal about the disk seek times is the only
idea which would convince me up to now. I am still riddling,
though, why this enlarges the need for fifo buffer capacity
but does not slow down the average data throughput.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dvd+rw-tools update [6.0, DVD-R DL]

[scdbackup]

Hi,

> > > > How come that the time granularity of the backup processing chain
> > > > does not get finer as the systems get faster ?
> > What effect did change the shape of our input functions ?
> 
> I think the main problem is that hard disk seek times have not
> improved anywhere nearly as fast as the CD/DVD writing speed. 

This looks like a valid reason, yes.
Disks get faster larger than they get faster.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

cdrtools cdrecord/cdrecord.c

[scdbackup]

Hi,

>  if ((flags & F_FORCE) == 0)
> -   comexit(EX_BAD);
> +;//comexit(EX_BAD);

You could achieve the same by causing  flags
to have the F_FORCE bit set.
My suspicion is that this can be done by option
  -force

It might be worth a try with the unpatched program.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dvd+rw-tools update [6.0, DVD-R DL]

[scdbackup]

Hi,

> > How come that the time granularity of the backup processing chain
> > does not get finer as the systems get faster ?
> 
> What do you understand by time granularity?

I see a fifo as a method to smoothen out peaks and gaps in a
input function and to bring the output nearer to the input
average.
The intensity of peaks and gaps resp. the deviation from the
average can be characterized by the time span in which one
may expect that those irregularities compensate each other.
The product of this time span and the average speed determines
the size which is needed for an effective buffer.
This time span is what i mean with "time granularity".

If the overall system gets faster, i would expect this 
characteristic timespan to get shorter. But it seems to
stay within the range of several seconds.
Since the average speed grew and the time staid more or
less the same, the fifo size had to grow.

The only logical explanation is that the characteristics
of the input function have changed while the system
became faster.


Other views which lead me to the same result:

My considerations about the benefits and effectivity of a fifo
always dealt with relative speeds of input and output. Never
with absolute speed.
Thus one would expect that if both input and output speed
increase in the same proportion, then the effectivity should
stay the same. But it obviously doesn't.

A simple thought experiment:
Imagine a movie of an old backup run which is shown at double
speed. The report messages about buffer size and buffer fill would
stay exactly the same.
If everything would have gotten faster by technical progress then
we would have exactly that highspeed movie situation. But we haven't.


> But oneproblem is that current drives have less internal RAM compared to
> older drives if you take the drive speed into account.

True. But were the drive buffers sufficient 4 years ago ?
If they weren't very effective in the past then their relative
diminishment would not be significant now. 

I'm still riddling.
What effect did change the shape of our input functions ?


> >   http://lists.debian.org/cdwrite/2004/cdwrite/2006/01/msg00057.html
> > A short answer would be welcome.
> 
> Well, some things that are not done immediately because of workload may be 
> forgotten if noone pings again.

You could have simply declared it a feature :))
How old did it become while being unnoticed ?


> *** 3737,3745 

With my copy of 2.01.01a4 it's in line 3565 ... make ...
... running again my reported test command ... 
  Track 01:  125 of  125 MB written (fifo 100%) [buf  99%]   8.0x.
  WARNING: padding up to secsize.
  Track 01: writing 300 KB of pad data.
  Track 01: Total bytes read/written: 131198521/131506176 (64212 sectors).
  ...
  Track 02:   38 of   38 MB written (fifo 100%) [buf  99%]   8.5x.
  WARNING: padding up to secsize.
  Track 02: Total bytes read/written: 40104790/40105984 (19583 sectors).

Ok, no padding reported on track 2. Is it readable ?
(The cdrom driver shows me both tracks as one continous stream.) 
  dd if=/dev/cdrom bs=1m skip=124 | afio -tvk - 2>&1 | less
Yep. afio can detect the start of the archive and reports all files.

Looks good.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dvd+rw-tools update [6.0, DVD-R DL]

[scdbackup]

Hi,

Joerg Schilling wrote:
> Guess why I recommend to use more than 128MB for the star FIFO
> in order to keep the tape streaming.
> 
> With current I/O speed, you need current RAM sizes for buffering.

Googling for contemporary speeds ... HP ... 36 MB/s DLT ... 80 MB/s LTO
... well, i'd need a new computer first.

How come that the time granularity of the backup processing chain
does not get finer as the systems get faster ? Since our fifos 
are mainly having an averaging effect, a finer granularity would
avoid the need to make them larger. But we clearly have to enlarge
them. We still have to prepare for a few realtime seconds of shortage.

There must be something negative growing with our faster systems. 
More processes which impose disturbance ? Larger amounts of disk data
and therefore larger disturbances ?
Compression ratios staid more or less the same. 2:1 as rule of thumb.


For something else:
In
  http://lists.debian.org/cdwrite/2004/cdwrite/2006/01/msg00057.html
i ask wether the current behavior of cdrecord with padsize= and
multiple tracks will be uphold or wether it will be changed to
comply to the man page.
A short answer would be welcome.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dvd+rw-tools update [6.0, DVD-R DL]

[scdbackup]

Hi,

> >>My standpoint is that if you get into situation when you consider more 
> >>than 64MB, it's likely that bottleneck is abnormal
> > Or the user is an aberrated personality like me who 
> > streams compressed archives on the fly. :))
> 
> Keep in mind that ring buffer harmonizes *variations* in input rate. It 
> can't possibly help if the stream can't be maintained at required rate 
> in *average*, no matter how large the buffer is. In other words I find 
> it hard to believe that on-the-fly compression of real-life data affects 
> required ring buffer size very much.

A fifo increases average throughput if the system can deliver
as peak performance more than the drive speed. Of course
the average write performance cannot be better than the
average data generation performance. A generously sized
fifo can bring both average performances nearer together.
That's because it can save more peak performance for future
use in dire times. (A data structure which transports peak
performance into the past has still to be developed.)

afio on my AMD 2600+ cheapo can deliver about 15 to 20 MB/s
speed as peak performance when reading precompressed data
from memory cached filesystem and it falls to arbitrary low
rates when redundant data achieve good compression ratios.
I found out that a 200 MB fifo can bring the average
write performance with my /opt and /home trees near to
3.0x DVD while a few weeks ago without fifo it was only about
2.2x. A fifo of 32 MB brings about 2.8x.
The CPU load during the backup run is clearly higher now
because afio and gzip can work more freely. (That was with my
own fifo but yours would give similar results.)

I am not sure wether the effect is only due to the buffered
peaks or also due to the decoupling of my suboptimal IDE
hardware.


> as you 
> still have to pull a lot of data from disk, you still put quite a 
> pressure on VM subsystem, so direct I/O can still help,

But how to talk afio, star or mkisofs into that ?
How to talk myself into streamlining my own processing pipeline ?
There's surely some 10% of CPU load to be squeezed.

To my luck, backup is better done with RW media and those
are limited to 4x speed usually. But if i imagine a 500 MHz
PC with a 4x DVD writer ... uh oh.


> > with 16x DVD a 64 MB buffer gives you just three seconds of
> > reserve.
> 
> Yes, which is why I wrote it's on the edge. But idea is also that 
> average Joe will get hypnotized by progress indicator and abstain from 
> pressing the buttons and cause massive page faults while the recording 
> is in progress anyway,

Don't forget Damian Demon and Chris Cron.
Those guys can stirr up a system too. Then there is my overly
smart ReiserFS (first name Hans) and the elevator man (Linus)
not to forget myself (in all my five multiple personalities).
A 4x DVD lasts nearly a quarter of an hour. Enough time to
forget about it and to start some compiler run.

There is always a reason to make the disk rattle. 
I can hear a bonking sound from the writer when its buffer
runs empty. With the fifo this sound became rare for uncompressed
ISO 9660 streams. (Compression is still bonking, of course.)


>  while technically minded users like ourselves 
> will figure out what's appropiate in any particular situation 
> [anyway too].

At least i try to take the consequences of my actions like a man:
with a stone face and not showing any sign of pain.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dvd+rw-tools update [6.0, DVD-R DL]

[scdbackup]

Hi,

> > (The jump between 64 and 128 MB might be a bit coarse.)
> 
> My standpoint is that if you get into situation when you consider more 
> than 64MB, it's likely that bottleneck is abnormal

Or the user is an aberrated personality like me who 
streams compressed archives on the fly. :))

> and it's more beneficial to seek other ways to work around it,

Psycho medication is too expensive in these days.
1 GB of RAM lasts longer and has less side effects.


Pun aside: with 4x DVD you are of course right. But with
16x DVD a 64 MB buffer gives you just three seconds of
reserve.
Computed back to the times of 2x CD-RW that would be a
fifo of less than 1 MB.

Whatever. The exponential progression matches nicely with
Moore's Law. Speed doubles, memory doubles, why shouldn't
the fifo double too ?
So for now i revoke my concerns. This fifo is good as it is.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]