Re: kern/48808

["Thomas Schmitt" <scdbackup%gmx.net@localhost>]

The following reply was made to PR kern/48808; it has been noted by GNATS.

From: "Thomas Schmitt" <scdbackup%gmx.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/48808
Date: Thu, 15 May 2014 12:19:20 +0200

 Or maybe i should just point to mscdlabel(8), and give a modest
 hint why it is not able to do what mount_cd9660 -s can do:
 
 --------------------------------------------------------------------
   -s block_offset
      Read the superblock from block address block_offset rather than
      from the default position implied by the choice of the device
      file.  The block size is 2048 bytes.
 
      Command mscdlabel(8) may have connected some /dev/cd* files to
      logical tracks of an optical multi-session medium, giving the
      device files the matching superblock positions for the recognized
      ISO-9660 filesystems.  Such a default offset will be overridden
      by option -s so that all /dev/cd* will behave like /dev/cd*d.
 
      mscdlabel(8) has limitations with finding all ISO-9660 sessions
      which are accessible via a storage device. The burn software
      suite which produced the ISO-9660 filesystem should be able to
      tell all suitable block_offset values.
 --------------------------------------------------------------------
 
 Actually the limitations of mscdlabel(8) applies even to CD media:
 How to represent the about 40 sessions which i could squeeze on a
 CD-R ? (Despite the wasted MBs between CD sessions.)
 How to represent a DVD+R with up to 150 sessions or a multi-session
 BD-R with up to 300 sessions ?
 
 Nevertheless, mscdlabel(8) could become a tool which tells block_offset
 values for mount_cd9660 -s. I will have a look at it ... later.