Re: [no subject]

[Thomas Schmitt]

Hi,

Harry Wang wrote:
> Sorry, my english is pool, so, some question maybe ungrammatical.

No problem, as long it is clear what you mean. I will ask if i don't
understand. You are invited to correct me if i possibly got you wrong.


> I rename "xorriso" and "libburn" with  "zfburn" and "zflibburn".

How did you do that ?
Did you change the names in xorriso/text_io.c function Xorriso_msgs_submit() ?


I asked:
> > - What was your exact command line to build it ?

> ./configure  without any other configration, (the default configration)

I see in file configure.ac that about 10 years ago i enabled the automatic
use of libcdio if ./configure runs on cygwin or mingw, if the libcdio
header file is present, and the library offers the API function
mmc_last_cmd_sense().

But i cannot remember who tested this for me or whether this was tested
at all. Possibly you are the first to try it.


> > - What operating system adapter does it use?

> libburn OS adapter:  sg-libcdio h20000 with libcdio 2.0.0 i686-pc-cygwin

My git clone of libcdio from 2020 reports the same versions "h20000" and
"2.0.0" for the header files the runtime library:

  libburn OS adapter:  sg-libcdio h20000 with libcdio 2.0.0 
x86_64-unknown-linux-gnu

But much of the work is done in libcdio's operating system drivers, of
which i cannot test the MS-Windows imp[lementations.
(In libcdio the "drivers" are its operating system specific code parts.)


> > - With both drives attached and loaded media in each of them:
> >  Does
> >     xorriso -outdev /dev/sr1 -toc
> >  yield a different result than with /dev/sr0 ?

>    Both of them are the same

So for some reason libcdio on MS-Windows picks one drive and uses it
regardless of the address argument which libburn submits to function
cdio_open_am().

Can you confirm this by using a silly drive name and forcing libburn
to use it as a real drive's name ?
Does this xorriso run show again the one drive that is always used ?

  xorriso -outdev mmc:silly_name -toc

Without prefix "mmc:" you will possibly get reported a future data file
as pseudo drive:
  Drive type   : vendor 'YOYODYNE' product 'WARP DRIVE' revision 'FX01'
  Media current: stdio file, overwriteable
  Media status : is blank
It would be interesting to know if you get this on MS-Windows too.

=========================================================================

My libcdio git clone seems to work with its Linux drivers, although on the
first try it got a hickup with xorriso -devices:

  libburn : SORRY : Could not grab drive '/dev/sr5' : Device or resource busy
  Full drive scan done
  -----------------------------------------------------------------------------
  0  -dev '/dev/sr4' rwrw-- :  'HL-DT-ST' 'BD-RE BH16NS40'
  1  -dev '/dev/sr0' rwrw-- :  'HL-DT-ST' 'BDDVDRW GGC-H20L'
  2  -dev '/dev/sr1' rwrw-- :  'HL-DT-ST' 'DVDRAM GH24NSC0'
  3  -dev '/dev/sr2' rwrw-- :  'HL-DT-ST' 'BD-RE GGW-H20L'
  4  -dev '/dev/sr4' rwrw-- :  'ASUS    ' 'BW-16D1HT'
  -----------------------------------------------------------------------------

But since then it reports what the Linux adapter reports

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

The only difference is that it lists sr5 first, whereas the Linux adapter
lists it last.

Using a silly name as MMC drive address yields no drive access:

  $ xorriso -outdev mmc:silly_name -toc
  ...
  xorriso : FAILURE : Cannot acquire drive 'mmc:silly_name'
  xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'

So on Linux it behaves quite different than on MS-Windows.

=========================================================================

I now dive into libcdio source.

Do you feel apt to modify libcdio, to compile and install it ?
Else i see few chance for finding out what exactly is going on.

In the libcdio source file lib/driver/device.c i see in

  cdio_open_am (const char *psz_orig_source, driver_id_t driver_id,
                const char *psz_access_mode)

that it picks a default drive if psz_orig_source is NULL or an empty string.
This is not the case with my experiments on Linux.
Because the funtion is not OS-specific, i assume that psz_orig_source is
submitted by libburn as non-empty string on MS-Windows too.

cdio_open_am() with driver_id DRIVER_DEVICE calls cdio_open_am_cd()
which calls

  scan_for_driver(const driver_id_t drivers[],
                  const char *psz_source, const char *access_mode)

In Linux this ends up in cdio_open_am_linux().
CdIo_all_drivers[] has as equivalent for MS-Windows a pointer to function

  cdio_open_am_win32 (const char *psz_orig_source, const char *psz_access_mode)

in lib/driver/MSWindows/win32.c .
In cdio_open_am_win32() a default drive is picked if psz_orig_source is NULL,
else

  cdio_is_device_win32(const char *source_name)

is called with psz_orig_source as source_name.
This function would return false if source_name was "/dev/sr0".
But obviously libcdio succeeds with opening the drive. So i conclude that
cdio_is_device_win32() is most probably not called with "/dev/sr0".


So the riddle is what kind of string the functions cdio_open_am(),
cdio_open_am_cd(), cdio_open_am_win32(), and maybe cdio_is_device_win32()
get as their first argument.

This is where i would need you to insert code which prints these first
arguments on entry of each of the functions.
(Take care to check for NULL as pointer value as a special case.)

Then run

  xorriso -outdev /dev/sr0

und watch for the messages from your inserted code.
Tell me what the mentioned functions see and whether they really get called.


Have a nice day :)

Thomas