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: Fri, 16 May 2014 08:31:24 +0200

 I finished my tests of the new mount_c9660 without finding
 problems, which were not present before.
 
 The test with mount(2) option MNT_UPDATE works insofar that the
 kernel refuses on the request to change the superblock offset
 (as i told it to do).
 
 But the usefulness of MNT_UPDATE resp -o update with the current
 implementation is questionable, because it seems to do nothing.
 A change from default rrip,joliet,maplcase by
   mount_cd9660 -o norrip,nojoliet,nomaplcase /dev/cd0a /mnt/iso
 would make sense.
 Among other things it would change
   -rw-r--r--  1 thomas  dbus  4294965248 Jun 23  2012 powerpc.img
   -rw-r--r--  1 thomas  dbus  4294965248 Jun 23  2012 powerpc.img
 to
   -r-xr-xr-x  1 root  wheel  2048 Jun 23  2012 POWERPC.IMG
 which is at least educational. (.. and would allow to concatenate
 the true 4 GiB file from both faulty representations. :))
 
 The implementation seems tricky, because parts of iso_mountfs()
 would have to be performed to verify the validity of the new
 options. Also i am uncertain about the impact on existing iso_node
 objects if mount flags get changed.
 
 UDF simply throws EOPNOTSUPP on MNT_UPDATE. But it also does it
 on udf_mountroot() which serves as struct vfsops.vfs_mountroot().