On Sun, 19 Feb 2012 09:47:29 -0500, Richard Thornton wrote:
Why not find a Windows box to dump the data to a Linux server?
Problem solved.
Because this isn't the first time I've noticed this, and last night I
finally hunted down specs and guessed around enough to figure out what
was going on--and also, I refuse to believe that OpenBSD is this
retarded. This was one of the first things that bugged me about it, back
when I first ever stuck discs into it. Also I have about 100gigs on DVD
and I want to minimize the hoops the data has to go through. Also I'd
have to beg friends for access to Windows.
I thought about this though! My last plan before sleeping last night
was to install linux in qemu on the server with sshd running and access
to cd0c and dump data that way--the virtual network lag should be far
less than real lag, but now thankfully I don't have to because Remco has
stumbled into the proper solution.
On Sun, 19 Feb 2012 16:41:44 +0100, Remco wrote:
Nick Guenther wrote:
Here's what cd-info(1) (for the archives: this is from package
libcdio)
has to say about a DVD that OpenBSD shows LFNs for:
~$ cd-info --dvd
[snip]
Disc mode is listed as: DVD-R
CD-ROM Track List (1 - 1)
#: MSF LSN Type Green? Copy?
1: 00:02:00 000000 data false no
++ WARN: number of minutes (501) truncated to 99.
170: 99:24:74 447224 leadout (1003 MB raw, 873 MB formatted)
__________________________________
CD An alysis Report
CD-ROM with ISO 9660 filesystem and joliet extension level 3
ISO 9660: 2256224 blocks, label `GOSHA_DOCUMENTS '
Application: NERO BURNING ROM
Preparer :
Publisher :
System :
Volume : GOSHA_DOCUMENTS
Volume Set :
~$
and one that OpenBSD shows SFNs for:
~$ cd-info --dvd
[snip common drive info]
Disc mode is listed as: DVD-R
CD-ROM Track List (1 - 1)
#: MSF LSN Type Green? Copy?
1: 00:02:00 000000 data false no
++ WARN: number of minutes (507) truncated to 99.
170: 99:16:26 446576 leadout (1001 MB raw, 872 MB formatted)
__________________________________
CD Analysis Report
ISO 9660: 2279017 blocks, label `G Save B 6 '
Application: EASY CD CREATOR 6.0 (171) COPYRIGHT (C) 1999-2003
ROXIO,
INC.
Preparer :
Publisher :
System :
Volume : G Save B 6
Volume Set :
UDF: version 0.00
and another:
Disc mode is listed as: DVD-R
CD-ROM Track List (1 - 1)
#: MSF LSN Type Green? Copy?
1: 00:02:00 000000 data false no
++ WARN: number of minutes (505) truncated to 99.
170: 99:57:63 449688 leadout (1008 MB raw, 878 MB formatted)
__________________________________
CD Analysis Report
ISO 9660: 2269454 blocks, label `G Save B 7 '
Application: EASY CD CREATOR 6.0 (171) COPYRIGHT (C) 1999-2003
ROXIO,
INC.
Preparer :
Publisher :
System :
Volume : G Save B 7
Volume Set :
UDF: version 0.00
So, obviously, the clue is that Roxio obviously didn't put Joliet
data
on the discs (grrr), which Nero did on the other one. But
nevertheless
the long file names *are* there because linux reads them. Is there
any
way to make OpenBSD find the long names anyway?
Thanks to all you lovely misc@ers,
-Nick
If I'm not mistaken your LFN disc only show ISO9660, the SFN discs
have an
additional "UDF: version 0.00" marker.
I've never used it so I don't know if it's the right tool for the job
but
there is mount_udf(8) on OpenBSD.
I'll leave it to you if you want to risk trying it, or wait for more
knowledgeable people to chime in.
Ahhh! You win!!
~$ sudo mount_cd9660 /dev/cd0c /mnt/cd0/
~$ ls /mnt/cd0/
AUDIO COMICS FONTS PROGRAMS
~$ mount | grep cd0
/dev/cd0c on /mnt/cd0 type cd9660 (local, read-only, norrip)
~$ #ALLCAPS is a symptom of 8.3 filenames on OpenBSD (n.b. part of
Linux's spec is
~$ #that it tolower()s 8.3 filenames to make them less scary, but also
less obvious)
~$ sudo umount /mnt/cd0
~$ sudo mount_udf /dev/cd0c /mnt/cd0/
~$ ls /mnt/cd0
Audio Comics Fonts Programs
~$ mount | grep cd0
/dev/cd0c on /mnt/cd0 type udf (local, read-only)
(again, for the records, because this confused me and isn't documented
anywhere) norrip means "no rock ridge interchange protocol", which is
OpenBSD complaining that your ISO is ghetto.
I just mounted the same disk on Linux and got this:
[kousu@splaat ~]$ sudo mount /dev/sr1 /mnt/cd1
Password:
mount: block device /dev/sr1 is write-protected, mounting read-only
[kousu@splaat ~]$ mount
/dev/sr1 on /mnt/cd1 type udf (ro,relatime,utf8)
So, conclusion: if you don't force it, Linux's mount(1) prefers to
mount as UDF, whereas OpenBSD falls back to cd9660. AND THE BELLS RANG
OUT.
Thanks a lot for your eyes, I probably would have given up and done the
qemu thing and then maybe next year noticed mount_udf and made the
connection.
-Nick
