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  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.
-> File Handling (?)
Assignee: asa → law
Component: Browser-General → File Handling
QA Contact: doronr → sairuh
This is mine. I'll take it.
Assignee: law → colin
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.
QA Contact: sairuh → nobody
After some experimentation, I made an important discovery: the cdrom drives that do not appear in the list are mounted ISO! cdrom drives that are mounted with normal vms files-11 volumes show up fine, as colin observed. I would happily live my life without ever mounting a ISO-format cdrom, but unfortunately Compaq has started distributing the vms documentation set in this format. Here is the sho dev output requested, though it is probably unnecessary now that colin knows how to recreate the problem: Disk LAUREL$DKA500:, device type DEC RRD47, is online, mounted, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 99 Owner process "" Owner UIC [0,0] Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 1 Default buffer size 512 Total blocks 1184484 Sectors per track 4 Total cylinders 49354 Tracks per cylinder 6 Host name "LAUREL" Host type, avail AlphaServer 1200 5/533 4MB, yes Volume label "VMSDOC073" Relative volume number 1 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 6 Mount status System ACP process name "DKA500CACP" Volume Status: ISO 9660. Volume is also mounted on LARRY, HARPO, HARDY, LAUREL, CURLY. Members of this volume set are LAUREL$DKA500: (rvn 1).
Is this new with V7.3? I only have up to V7.2 CD's, and I've never had to mount ISO 9660 format. Just curious...
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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...
I don't know whether you noticed it or not, but there is another factor in the equation. The cdrom is not directly connected to the machine running mozilla (MOE); it is mscp-served from node LAUREL. This could have something to do with it. I have noticed on occasion that show dev is not identical when done from another node in the cluster. Therefore, to completely recreate my scenario, you need to take that microsoft cdrom and mount it on another cluster node, and *then* try to access it from mozilla. That said, here is the requested output: LAUREL$DKA500 DEC RRD47 UCB: 811C3780 Device status: 08021810 online,valid,unload,lcl_valid,exfunc_supp Characteristics: 1E4D4008 dir,fod,shr,avl,mnt,elg,swl,idv,odv,rnd 25010221 clu,mscp,nnm,nlt,scsi,nofe,dtn Owner UIC [000000,000000] Operation count 99 ORB address 81014040 PID 00000000 Error count 0 DDB address 811C39C0 Alloc. lock ID 090008B8 Reference count 1 DDT address 824D15A0 Alloc. class 0 Online count 1 SUD address 81166AC0 Class/Type 01/36 BOFF 00000000 VCB address 81256040 Def. buf. size 512 Byte count 00000000 CRB address 811951C0 DEVDEPEND C0CA0604 SVAPTE 00000000 PDT address 81120660 DEVDEPND2 00000000 DEVSTS 00000004 CDDB address 811C20C0 DEVDEPND3 00000000 RWAITCNT 0000 I/O wait queue 811C37EC FLCK index 3A DLCK address 00000000 Device DEVSTS status: 00000004 nocnvrt -- Device Path Information -- Displayable Path Information: MSCP --- Primary Class Driver Data Block (CDDB) 811C20C0 --- Status: 00000040 alcls_set Controller Flags: A004 cf_mlths,cf_load,cf_replc Allocation class 0 CDRP Queue 811C20C0 DDB address 81195140 System ID 0000040F Restart Queue 811C2108 CRB address 811951C0 00000000 DAP Count 0 CDDB link 00000000 Contrl. ID 0000040F Contr. timeout 20 PDT address 81120660 01040000 Reinit Count 0 Original UCB 00000000 Response ID 00000000 Wait UCB Count 0 UCB chain 8118D400 MSCP Cmd status FFFFFFFF *** I/O request queue is empty *** --- Volume Control Block (VCB) 81256040 --- Volume: VMSDOC073 Lock name: VMSDOC073 Status: 80 system Status2: 04 mountver Status3: 00000000 Mount count 1 Rel. volume 1 AQB address 812B4040 Transactions 1 Max. files 0 RVT address 81208780 Free blocks 888666 Rsvd. files 0 FCB queue 81256040 Window size 76 Cluster size 2048 Vol. lock ID 0D000F00 Def. extend sz. 1 Record size 0 --- ACP Queue Block (AQB) 812B4040 --- ACP requests are serviced by process DKA500CACP whose PID is 00060016 Status: 04 defsys Mount count 1 ACP type f11v3 Linkage 8124F940 ACP class 129 Request queue 00000000 *** ACP request queue is empty ***
Good point. I'll bet that's it. I bet $device_scan doesn't show remote devices.
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.
Can you run this and tell me if it shows LAUREL$DKA500 $ start: $ device_name = f$device("*","disk") $ if device_name .eqs. "" then exit $ str = device_name $ if f$getdvi(device_name,"avl") then str = str + " AVL" $ if f$getdvi(device_name,"mnt") then str = str + " MNT" $ write sys$output str $ goto start
MOE> submit x Job X (queue MOE_BATCH, entry 860) started on MOE_BATCH MOE> Job X (queue MOE_BATCH, entry 860) completed MOE> sear home:x.log dka5 _LAUREL$DKA500: AVL MNT _LARRY$DKA500: AVL MNT _CURLY$DKA500: AVL MNT MOE>
This doesn't make sense. I need to think about this some more. Thanks for your help so far. We will get to the bottom of this!
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.
MOE> copy LAUREL_DISK4:[WAYNE_NOPRIV]SHOWATTACHMENT.CGI x.c %COPY-S-COPIED, LAUREL_DISK4:[WAYNE_NOPRIV]SHOWATTACHMENT.CGI;1 copied to LAUREL $DKB300:[SCRATCH_AREA]X.C;16 (5 blocks) MOE> cc x MOE> link x MOE> run x _MOE$DKB0: AVL MNT _MOE$DKB100: AVL MNT _MOE$DKB300: AVL _MOE$DQA0: AVL _MOE$DQA1: AVL _MOE$DQB0: AVL _MOE$DQB1: AVL _MOE$DVA0: AVL _LAUREL$DKB0: AVL MNT _LAUREL$DKB100: AVL MNT _LAUREL$DKB300: AVL MNT _LAUREL$DKA500: AVL MNT _LARRY$DKA0: AVL MNT _LARRY$DKA100: AVL MNT _LARRY$DKA200: AVL MNT _LARRY$DKA300: AVL MNT _LARRY$DKA500: AVL MNT _LARRY$DKA600: AVL _LARRY$DVA0: AVL _HARDY$DKA0: AVL MNT _HARDY$DKA400: AVL _HARDY$DKB100: AVL MNT _HARDY$DKB200: AVL MNT _HARDY$DKB400: AVL MNT _HARDY$DKB500: AVL MNT _HARPO$DKA100: AVL _CHICO$DKA0: AVL _CHICO$DKA100: AVL MNT _CHICO$DKA200: AVL MNT _CHICO$DKA300: AVL MNT _GROCHO$DKA0: AVL _GROCHO$DKA200: AVL _GROCHO$DKA400: AVL _GUMMO$DKA200: AVL _CURLY$DKB100: AVL MNT _CURLY$DKB200: AVL MNT _CURLY$DKB300: AVL MNT _CURLY$DKB400: AVL MNT _CURLY$DKB500: AVL MNT _CURLY$DKA500: AVL MNT MOE> It appears the laurel cdrom is being seen in the scan. I've got no explanation, other than maybe the cdrom is being removed from the list, based on unknown criteria, at some point *after* the scan.
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.
Attachment #54653 - Attachment description: Test C program → device_scan program
It appears you have found the problem! Rather than dismount/remount, I just ran stat on two different cdroms, one mounted iso, the other regular ods-2 (the drive on curly). It looks like you will have to use some other method to identify iso volumes. MOE> cc stat MOE> link stat MOE> $ mcr stat "/laurel$dka500/000000" stat(/laurel$dka500/000000) returned -1 stat: no such file or directory MOE> MOE> $ mcr stat "/curly$dka500/000000" stat(/curly$dka500/000000) returned 0 st_ino (4,4,0) st_dev _CURLY$DKA500 st_mode 0x416d (DIR) st_size 1024 st_uid 65540 (0x10004) [1,1] st_gid 1 (0x1) st_ctime 995993599 - Tue Jul 24 11:53:19 2001 st_atime 995997489 - Tue Jul 24 12:58:09 2001 st_mtime 995997489 - Tue Jul 24 12:58:09 2001 st_fab_rfm (record format) 2 (VAR) st_fab_rat (record attributes) 0x8 (0,0,0,MSB BLK,PRN,CR,FTN) st_fab_fsz (fixed header size) 0 st_fab_mrs (record size) 512 MOE> The weird part is that you can do: MOE> dir laurel$dka500: Directory LAUREL$DKA500: AUTORUN.INF;1 BIN.DIR;1 EXE.DIR;1 EXTRA.DIR;1 IMAGES.DIR;1 INDEX.HTML;1 INDEX_FILES.DIR;1 OVMS_ARCHIVED.DIR;1 V73.DIR;1 VAX_INDEX.HTML;1 Total of 10 files. MOE> All I can figure is that the 000000.dir file doesn't actually exist and that the acp simulates it or something.
Sure enough, if you compare the  directories of both cdroms you get: MOE> dir laurel$dka500: Directory LAUREL$DKA500: AUTORUN.INF;1 BIN.DIR;1 EXE.DIR;1 EXTRA.DIR;1 IMAGES.DIR;1 INDEX.HTML;1 INDEX_FILES.DIR;1 OVMS_ARCHIVED.DIR;1 V73.DIR;1 VAX_INDEX.HTML;1 Total of 10 files. MOE> dir curly$dka500: Directory CURLY$DKA500: 000000.DIR;1 ADA035.DIR;1 ALPHA_FORT074B.DIR;1 APPDEV010.DIR;1 AXPGKS065.DIR;1 AXPGKSRT065.DIR;1 AXPPHIGS050.DIR;1 AXPPHIGSRTO050.DIR;1 BACKUP.SYS;1 BADBLK.SYS;1 BADLOG.SYS;1 BASIC014.DIR;1 BITMAP.SYS;1 CC064.DIR;1 CDROM.DIR;1 COBOL027.DIR;1 CONTIN.SYS;1 CORIMG.SYS;1 CXX063.DIR;1 INDEXF.SYS;1 OPEN3DB049.DIR;1 PASCAL058.DIR;1 SECURITY.SYS;1 VOLSET.SYS;1 Total of 24 files. MOE> Note that 000000.DIR;1 appears on the ODS-2 disk, but *not* on the iso. So there is no actual 000000.dir file. vms just simulates it if you ask for it. The stat fails because it is looking for an actual 000000.dir file.
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: 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.
If so, the regression occurred earlier than 7.3 because a 7.2-1 system gets the same error. MOE> ssp OpenVMS V7.3 on node MOE 23-OCT-2001 09:01:23.18 Uptime 7 00:54:14 MOE> $ mcr stat "/laurel$dka500" stat(/laurel$dka500) returned -1 stat: non-translatable vms error code: 0x186D4 %rms-f-syn, file specification syntax error MOE> HARPO> ssp OpenVMS V7.2-1 on node HARPO 23-OCT-2001 09:07:20.62 Uptime 8 23:20:39 HARPO> mcr stat "/laurel$dka500/000000" stat(/laurel$dka500/000000) returned -1 stat: no such file or directory HARPO>
Thanks for the extra datapoint. It works on my 7.1-2 system. I'll let you know what I find out from the CRTL folk. I've already posted the problem report.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.