Problem mounting CD-ROM with funny label

[Steven Schweda]

Note: "Problem", not "Issue".

Ok, there I was with a fresh picture CD from
the photo store, and my usual automatic
how-do-I-know-what-the-label-is mount procedure
spit up. Here's the essence on an XP1000:

ALP2 $ write sys$output f$getsyi( "version")
V8.3

ALP2 $ MOUNT /NOASSIST /OVERRIDE = IDENTIFICATION /NOWRITE cd1
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-CDROM_ISO, 05_29_07_3036: (1 of 1) , mounted on _ALP2$DKA400:

ALP2 $ LABEL = F$GETDVI( "cd1", "VOLNAM")

ALP2 $ write sys$output "''label'"
05_29_07_303

which is incomplete, so naturally:

ALP2 $ dismount cd1

ALP2 $ MOUNT /SYSTEM /NOASSIST /NOWRITE cd1 "''LABEL'"
%MOUNT-F-INCVOLLABEL, incorrect volume label
-MOUNT-I-CDROM_ISO, 05_29_07_3036: (1 of 1) , MOUNT FAILURE


I'd settle for either an elegant solution or a
clever work-around.

[Karl Rohwedder]

a /MEDIA=CDROM doesn't help, I suppose?

regards Kalle

[Dean McGorrill]

Hi Steven,
well I'll assume v8.3 still has 12 char
vol label restriction. (I don't have anything here booted with it)
at least with the over=id mount,
you can get the data to a disk, then rewrite
it do a cd with a shorter label. I know thats
not elegant. Dean

[Steven Schweda]

Nah. The problem is not in the MOUNT, it's
in the F$GETDVI(). I should have included
this in the exhibit:

ALP $ mount /noass /syst /nowrit cd1 05_29_07_3036
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-CDROM_ISO, 05_29_07_3036: (1 of 1) , mounted on _ALP$DKA600:

(This time on a VMS V7.3-2 system.)

There seems to be at least one 12-byte buffer
which could use a few more bytes.

alp $ show devi /full cd1

Disk ALP$DKA600:, device type TOSHIBA DVD-ROM SD-M1711, is online, mounted,
[...]
Volume label "05_29_07_303" Relative volume number 1
[...]

It's a trend.

(At least no one should be tempted to suggest
parsing a "SHOW DEVICE /FULL" report to get
the _real_ label. That's a mercy.)

[Steven Schweda]

> I'll assume v8.3 still has 12 char
> vol label restriction.

Yes and no. It apparently has a 12-character
restriction on the label it _reports_, but it
clearly doesn't have one on the label it
_demands_.


It's a little like the FTP server which
_displays_ ODS5 extended file names with the
caret-escapes, but which won't _accept_ a
file name which contains them.


I'm not whining again, am I? I like to
reserve the whining for the screen saver
(that is, screen waster) which won't persuade
any display I own to go into power-down
mode.

[Hoff]

A look at the ISO-9660:1988 specs is in order, to see what the legal label length might be. If this is a legal label, then MOUNT should handle it.

As you surmise, this is likely something emitted up from within the ODS-3 or ODS-4 support -- from the ISO-9660:1988 support within OpenVMS -- that $getdvi and MOUNT are not dealing with correctly.

ODS-3 and -4 haven't changed in any significant way in a while, and omit support for several very common extensions, and omit support for the ISO-9660:1999 volume structures.

This is fodder for a formal report -- that'll get this in front of whomever is maintaining MOUNT and whomever owns the ISO-9660:1988 volume structures. But you're here, which implies you probably don't have a software support contact.

Ugly workaround: mount the disk on Mac OS X or Linux box manually or via remote services, and copy the giblets over.

Or continue to use the override mechanism, and (if you get a INCVOLLABEL) replicate the contents over into a just-created LD. (Ok, so I almost always have a 700 MB LD hanging around.) There are occasionally some oddnesses around the file structures and around how the ISO-9660:1988 or :1999 volume itself was constructed, use of /undefined_fat can sometimes be required.

[Steven Schweda]

> [...] that $getdvi and MOUNT are not
> dealing with correctly.

As I said, MOUNT's happy in general, just not
with the output from F$GETDVI. (I haven't
tried the real $GETDVI to see if it does any
better, but I suspect that it would, given a
bigger buffer.)

> But you're here, which implies you probably
> don't have a software support contact.

You mean that this _isn't_ formal support?

Actually, ever since the ITRC Thought Police
removed my complaint about BACKUP /VERIFY
failing on symbolic links, I like to complain
here first, just to see what will happen.
_Then_, I move on to a _formal_ complaint to
the "Send us your comments" Web page. The
folks there always seem to be happy to hear
from me.


And that's "to whoever is maintaining MOUNT",
not "whomever". Where do you think you are,
comp.os.vms? (Think of it as "to
[her/him/it] who[ever] is maintaining MOUNT",
if the "to" is causing confusion. It may be
that "whoever is maintaining MOUNT" forms a
noun clause, and the whole thing is the
object of the propostion, but in any case
(har-har-har), "whoever is" is what needs to
agree, not "to whomever".)

[Dean McGorrill]

Steven,
I'm glad you report stuff, and others.
I can tell you we (decnet,decnet+) wanted problems reported, esp crashs. And I'm surprized how many folks
don't. My last contract they had a nasty tcpip
crash, I offered to report and work it and
they didn't want me to! I would have got
the dump to hp if I could.. Dean

[Steven Schweda]

Hmmm. $GETDVI using an item code of
DVI$_VOLNAM seems to return only 12
characters (to a 32-character buffer).

dvidef.h does say:

#define DVI$_VOLNAM 34 /* Volume name - STRING - 12 bytes */

So the 12 is not a complete mystery, I
suppose. Is there some magic item code for a
longer name which I'm just not seeing?

[John Gillings]

Steven,

Not particularly elegant or clever, but...

If you can successfully mount the disk using the label returned by MOUNT in the status message, then you can catch it using PIPE. Something like this (untested):

FINDLABEL.COM
$ OPEN/READ in SYS$PIPE:
$loop: READ/END=endloop in rec
$ IF rec-"MOUNT-I-CDROM_ISO".EQS.rec THEN GOTO loop
$ lab=F$ELEMENT(1," ",F$EDIT(F$ELEMENT(0,":",rec),"COMPRESS"))
$ DEFINE/JOB CDROM_ISO_LABEL 'lab'
$ endloop: CLOSE in
$ EXIT

Now, perform your mount:

$ PIPE MOUNT/whatever... | @FINDLABEL
$ DISMOUNT
$ MOUNT/whatever cd1 'F$TRNLNM("CDROM_ISO_LABEL")

It is possible to inline the PIPE, but it gets a bit complex

[Robert Brooks_1]

While I no longer work in VMS Engineering, and don't deal with $GETDVI, I'm still interested whenever unexpected behaviour is noticed.

Take a look at the offsets for the VCB structure, most easily seen in sys$library:lib.req. You'll see that vcb$t_volnam is at offset 32, and overlaid with vcb$t_volidentifier. The next cell is at offset 96 (vcb$q_mounttime). However, you'll see right before that the two "contants" of vcb$s_volname = 12 and vcb$s_volidentifier = 32. I suspect that the volidentifier stuff was added for non-ODS 2/5 support.

In [SYS]SYSGETDVI.MAR (at label SPC_VOLNAM:), you'll see that the max expected length is hardcoded at 12, which obviously needs some attention. I'll bug someone tomorrow.

However, it would make everyone's lives a bit easier if there was a formal complaint logged. I'm not saying that it won't get fixed without a formal call logged, but it gets attention if there's a paying customer who is annoyed.

Fortunately, it's a simple fix. Don't expect to see a fix for V7.3-2, however, since it's not under standard support.

-- Rob

-- Rob

[Steven Schweda]

> Not particularly elegant or clever, but...

Yeah, I thought about doing something like
that, but I was hoping for more elegance
and/or cleverness. Like a secret lexical
thing.

> It is possible to inline the PIPE, but it
> gets a bit complex

It's already in a procedure, so adding more
mess is only annoying, not prohibitive.

> [...] it gets attention if there's a paying
> customer who is annoyed.

You mean there are people who _pay_ for this
stuff? I guess I _have_ seen that, but it's
been a while. As I said, being a lowly
Hobbyist, the "Send us your comments" Web
page is about as close to "formal" as I can
get, but if more formality would help, I
wouldn't object to some paying volunteer
sending in one of those 8-part SPR forms.
(Press firmly.)

> Don't expect to see a fix for V7.3-2, [...]

I can dream, can't I? I suppose that I don't
really _need_ Appletalk these days, so I'm
not sure that I can justify holding back much
longer, but, as I always say, change is bad.

[Robert Brooks_1]

After some investigation, it appears as though the problem is a bit more involved. I was under the mistaken assumption that the full volume label was correctly stored in the VCB, and that $GETDVI was not returning the full string.

As it turns out, the full volume label isn't being stored, even though the MOUNT command does echo back the full label. Thus, any fix that needs to be done would involve (at least) MOUNT and the mount verification code, which is, uh, a bit less than straightforward
(for folks with the sources, look at [SYS]MOUNTVER.MAR).

Now, only the first 12 characters of the label are stored; the extended field (vcb$t_volidentifier) is not referenced anywhere in the VMS sources.

A perverse way to work around the problem is this . . .

$ MOUNT/OVER=ID foo

This rather surprising command will ignore the actual (long) volume name and replace it with "foo" (a $ SHOW DEVICE/FULL command will verify this). The confusing thing is that the MOUNT command echos back the original volume label, but doesn't use it. A secondary message indicating that the alias is being used would be a reasonable enhancement.

This was discovered by code inspection, where this behaviour is actually documented, so it's not simply some weird unintended side effect; it's a weird intended effect!

-- Rob

[Steven Schweda]

> A perverse way to work around the problem
> is this . . .

Only part of the problem. The original
complaint involved MOUNT /SYSTEM, and the
incompatibility between /SYSTEM and
/OVERRIDE = IDENTIFICATION is what started
this whole exercise in the first place.

Everything's complicated, I always say.

[Willem Grooters]

IIRC:

MOUNT - as such - requires a label to check whether the right volume is loaded. If the label is correct, it will mount the device and signal (part of) the found label.In yourr case, "LABEL" does not match the label so mount fails. (What happens if you specify:
$ MOUNT/SYSTEM cd1 "05_29_07_3036: (1 of 1)" or even
$ MOUNT/SYSTEM cd1 "05_29_07_303"

If /OVERRIDE, the device will be mounted regardless the the label, and show (part of) the found label.

The limit of 12 characters is consistent with SET VOLUME/LABEL adn INIT. Both specify 12 characters as a max for disk labels.

I guess that CD/DVD are considered "disk", and that the driver (DK, DQ?) will just allow these 12 characters be stored internally, but the full label will be shown on mount. Even more: what about characters that are not allowed in VMS terms? The caharcters ( and ) are not recommended...

I complained on 2005's bootcamp about the fact you're not able to post problems like this if you don't have a support contract - as if you're not a costomer. ITRC was said to be the "answer". Ok unless HP doesn't check it (they do, I'm told) or remove entries they don't like. (If OpenSource products have a bug forum, why shouldn't OpenVMS have one?)

[Steven Schweda]

> What happens if you specify: [...]

Oops. I omitted that experiment, too:

ALP $ mount /over = id cd1
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-CDROM_ISO, 05_29_07_3036: (1 of 1) , mounted on _ALP$DKA600:
ALP $ dism cd1

ALP $ mount /noass /system cd1 "05_29_07_3036: (1 of 1)"
%MOUNT-F-INCVOLLABEL, incorrect volume label
-MOUNT-I-CDROM_ISO, 05_29_07_3036: (1 of 1) , MOUNT FAILURE

ALP $ mount /noass /system cd1 "05_29_07_3036"
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-CDROM_ISO, 05_29_07_3036: (1 of 1) , mounted on _ALP$DKA600:

So, everything's worse than you might hope.

[Robert Brooks_1]

Ok unless HP doesn't check it (they do, I'm told) or remove entries they don't like. (If OpenSource products have a bug forum, why shouldn't OpenVMS have one?)

---

It should be pretty apparent by now that several of us HP folk monitor this forum and comp.os.vms and take reports of problems quite seriously, independent of whether or not the complainant has a support contract.

For what it's worth, when I raised this issue with a few folks in VMS Engineering, no one asked (or likely cared) if the person reporting the bug had a support contract.

We dislike bugs even more than you do.

-- Rob