Status

For issues dealing with helper applications, and guessing
Content Types when they aren't specified/known (ftp:, file:, jar:, but generally not http:). This component does not cover: backend networking issues, such as those covered by Networking: FTP or Networking: File, nor does it cover the Download Manager which has its own component in Toolkit.

On the open file option, if one continues hitting the ".." button, eventually
a list of disk drives appears, allowing one to select a disk and walk down
the desired directory tree to the desired file.
However, CDROM drives do *not* appear in this list, only regular magnetic disk
drives. A lot of documention is provided on CDROM in HTML form. Since the
cdrom drives to not appear in the list, one cannot use the menu and is forced to
enter the full file name of the html index file manually. Fortunately, the
index file is normally in the [000000] directory. Even more fortunately, the
remainder of the html files are accessed normally, i.e. by clicking on links
from the index file.
This is not a big problem, but I don't see a reason why cdrom drives should be
excluded from the drive list. It appears to have nothing to do with whether a
cdrom drive is mounted or not. Of course one would not expect unmounted drives,
optical or magnetic, to appear in the list. However, I have verified that
cdroms still do not appear in the list even when they are mounted at the time
mozilla is started.

I just tried this and it works for me. So long as the CD drive is mounted
(either private or system, doesn't matter), then it shows up with all the other
disk devices.
Can you do a SHOW DEVICE /FULL on your CD drive.

Yes, this is new with 7.3, another example of the purity of vms compromised by
the billyworld, like ODS-5 and MIME. I suppose it makes sense for those people
who want to read the vms documents from a billybox. I would rather do it with
mozilla on a vms system, so ods-2 was fine for me.

Strange. On my test system (V7.1) I can stick a Microsoft CD in my drive and
mount it. A show device shows it mounted ISO 9660. Then I fire up Mozilla and do
an Open File, ".." up all the way to top, and voila, the CD is there.
So why doesn't it work for you? What is different about (a) VMS V7.3 or (b) the
VMS V7.3 doc cd?
What the code does is a $device_scan for all disks, but discards any it find
that do not have both the MOUNTED and AVAILABLE bits set in their devchar. ISO
9660 mounted disks should meet all these requirements. They certainly do on my
system!
So, next request. Mount the CD and go into ANAL/SYS, and do a SHOW DEVICE
DKA500, and post the results here. There's got to be something different...

It probably does in general, since regular magnetic disks show up just fine when
mounted on other nodes, as do cdroms mounted ods-2. It appears to be the
combination of remote and iso. Either the remote iso disk doesn't show up in
the scan at all, or mozilla is scanning it, but seeing it and rejecting it
because a critical bit isn't set or something like that.

Wayne, I'm going to attach a small C program. Can you build and run this from
the account where you run Mozilla. Its basically a copy of the code that Mozilla
is using to determine which devices to show at the "root" of the file system.

Good, this is progress. Let's see what stat() gives us. I'll attach a stat
program next. Can you mount a normal (not ISO 9660) CD and do:
$ mcr []stat "/laurel$dka500/000000"
and then mount the ISO 9660 CD repeat.
I suspect that stat() is giving us something to cause a rejection.

Excellent! I'll report this to the CRTL folks. This appears to be a regression
because on my V7.1 system I can mount an ISO 9660 CD and although a DIR of
DQA0:[000000] will not show any 000000.DIR, a stat of "/dqa0/000000" does work.
One last request. I know this never used to work, but maybe it does in V7.3. Can
you try this for me:
$ mcr []stat "/laurel$dka500"
Colin.

On a CRTL test image I have stat("/dka400/000000") is working again for ISO 9660
CD's. Not only is the problem fixed but now even stat("/dka400") works!
I'm trying to find out when we can expect to see this fix in V7.2-1 and V7.3 ECO
kits.

The current estimate for a CRTL ECO which will fix this problem is some time in
December.
Closing this report since (a) there's nothing in Mozilla to fix, and (b) we have
a timeframe for the fix from Compaq.