[Debburn-devel] Minor problems with cdrkit-1.1.0

[scdbackup at gmx.net]

Hi,

> ... what happened in the beginning?

Nothing that seems worth reporting. 
Looks like MAGIC_ERROR is profanely missing in <magic.h>
(See below, after cmake messages)

> Complaints about missing magic.h maybe?

vim finds no match of "magic" but some of "MAGIC".
You may have the complete output. Just tell me where to
send it.

...
-- Performing Test LIBC_SCHED - Success
-- Looking for include files USE_MAGIC
-- Looking for include files USE_MAGIC - found
-- Looking for getopt_long
-- Looking for getopt_long - found
...
[ 48%] Building C object genisoimage/CMakeFiles/genisoimage.dir/genisoimage.o
[ 49%] Building C object genisoimage/CMakeFiles/genisoimage.dir/apple.o
/home/stacker/cdrkit_dir/cdrkit-1.1.0/genisoimage/apple.c: In function `hfs_init':
/home/stacker/cdrkit_dir/cdrkit-1.1.0/genisoimage/apple.c:2410: error: `MAGIC_ERROR' undeclared (first use in this function)
/home/stacker/cdrkit_dir/cdrkit-1.1.0/genisoimage/apple.c:2410: error: (Each undeclared identifier is reported only once
/home/stacker/cdrkit_dir/cdrkit-1.1.0/genisoimage/apple.c:2410: error: for each function it appears in.)
make[3]: *** [genisoimage/CMakeFiles/genisoimage.dir/apple.o] Error 1
make[3]: Leaving directory `/home/stacker/cdrkit_dir/cdrkit-1.1.0/build'
make[2]: *** [genisoimage/CMakeFiles/genisoimage.dir/all] Error 2
make[2]: Leaving directory `/home/stacker/cdrkit_dir/cdrkit-1.1.0/build'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/stacker/cdrkit_dir/cdrkit-1.1.0/build'
make: *** [all] Error 2


Searching for magic.h on my system

  # find /usr/include -name magic.h
  /usr/include/magic.h         Copyright (c) Christos Zoulas 2003.
  /usr/include/magick/magic.h  Seems unrelated

The file in /usr/include ideclares magic_*() functions and
defines macros up to 
  #define MAGIC_CHECK     0x40    /* Print warnings to stderr */
I guess MAGIC_ERROR has a higher single-bit number (0x200 ?).


> O-Ha. Please do "make clean" and then run "make build/Makefile" 

Tomorrow. It's after midnight. :) 

If above lack of a MAGIC_ERROR in magic.h doesn't explain
it all, anyway. cmake would have to examine every macro to
detect such a lapse.


> TERM=dumb make

Thanks. :))


> > collection which simulates a busy (or ill behaving) drive by
> > linking /dev/sg7 to /dev/sg1.
> >   Error trying to open /dev/sg7 exclusively (Device or resource busy)...
> Printing this message is the direct result of getting errno==EBUSY. Is
> your drive mounted?

No. It's wodim alone. Standing on its own foot, i assume.
My theory is that /dev/sg1 is still open from the the
ongoing bus scan (O_EXCL, i assume) when /dev/sg7 tries
to do the same. /dev/sg7 is a symbolic link. So open(O_EXCL)
would indeed be performed on the same device file.

>From behind my chinese wall i would bet cdrecord is staying
off /dev/sg7 because it is a softlink. As non-superuser it
aborts about idle device file /dev/sg2 because of no rw-perms.
But as superuser it can stand them all.

My reciepe for the link situation
  # ls -l /dev/sg7
  crw-r-----    1 root     disk      21,   7 Sep 23  2003 /dev/sg7
  # rm /dev/sg7
  # ln -s sg1 /dev/sg7
Now wodim cannot scan the bus any more. 
At /dev/sg1 there is my LG burner.
  # rm /dev/sg7
Now wodim's bus scan works again.
To get back my original sg7 i could execute:
  # mknod /dev/sg7 c 21 7


> It [wodim] tries three times before giving up and continueing with
> the next drive.

That would be nice. But the bus scan aborts:
  # wodim -v -scanbus
  TOC Type: 1 = CD-ROM
  Linux sg driver version: 3.1.25
  Error trying to open /dev/sg7 exclusively (Device or resource busy)... retrying in 1 second.
  Error trying to open /dev/sg7 exclusively (Device or resource busy)... retrying in 1 second.
  Error trying to open /dev/sg7 exclusively (Device or resource busy)... retrying in 1 second.
  Error trying to open /dev/sg7 exclusively (Device or resource busy)... retrying in 1 second.
  Error trying to open /dev/sg7 exclusively (Device or resource busy)... giving up.
  wodim: Device or resource busy. 
  Cannot open SCSI driver!
  For possible targets try 'wodim -scanbus'.
  For possible transport specifiers try 'wodim dev=help'.
  For IDE/ATAPI devices configuration, see the file README.ATAPI.setup from
  the wodim documentation.
  #

With recent cdrecord abort-happiness is even worse. There is
a bus scan with any run, even with explicit dev=... . But my
/dev/hdg DVD-ROM makes trouble with dev=ATA -scanbus :
  cdrecord-2.01.01a21-hz100: Read-only file system.
    Cannot open '/dev/hdg'. Cannot open SCSI driver.
Result: cdrecord 2.01.01a21 is not usable on SuSE 9.0 at all.
In a22 the automatic part of the ATA bus scan is disabled for
kernel 2.4 . So it works for me again. dev=ATA now complains:
  cdrecord-2.01.01a22: No such file or directory. 
    Cannot open '/dev/hd*'. Cannot open SCSI driver.   
Nevertheless, this mandatory bus scan invites trouble.
I must know. libburn was champion in bus scanning.

libburn is more realistic: 
What does make trouble does not exist.
(Only growisofs does it better than this: no bus scan at all)


> faked bus numbers to something plus 1000.

To my observations:
ATA:100X,Y,0 replaced ATA:X,Y,0
ATAPI:X,Y,0 is still the same (as of a21)
100X,Y,0 is the same as ATA:100X,Y,0

cdrskin-0.2.7 already accepts the 1000+ busses accordingly.
I'm waiting a few more a-releases and will then probably
list them with -scanbus too.
(Shrug. It was work to *split* the bus scan. Only a few
weeks ago.)


> Btw, what do you think about making -stream-file-name work again?

According to the man page of mkisofs, -stream-media-size
is still available. 
I understand -stream-file-name would allow to get a name
different from STREAM.IMG as result of -stream-media-size .

You should look into Paul Serice's "flyisofs" for a
more general concept of stream-input ISO generating.
  http://www.serice.net/shunt/

My backup tool got rather demand for a feature which
allows to cut pieces out of large files and graft them
into a ISO image which is written to stdout.
That's because i burn either open ISO trees with all files
in random access or raw archives without an ISO-9660 wrap.
For the ISO variant, i want to avoid files larger 2 GB.
Currently i have to copy the file pieces to a buffer
directory and then graft them into the image via normal
mkisofs target=source pathspecs.
That buffering is annoying. Imagine 25 GB BD-RE media.
If only mkisofs could copy those pieces directly into
its image.

A very widely exploitable gesture would be a special
pathspec which gives a target name, a size and a shell
command with arguments of which the output is to be
put as target file content into the ISO image. Nicely
truncated respectively padded to match the announced
size.
One could encrypt, cut pieces, add checksums ...
anything with a well predictable output size.


Have a nice day :)

Thomas