Closed Bug 105813 Opened 23 years ago Closed 23 years ago

cdrom drives do not appear in open-file drive list

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Platform:
DEC
OpenVMS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: wayne.sewell, Assigned: colin)

Details

Attachments

(2 files)

device_scan program
2.03 KB, text/plain
Details
stat program
1.90 KB, text/plain
Details 
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.
-> 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.
Keywords: qawanted
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.
Attached file device_scan program — 

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached file
          
        stat program
        — 
      

    


  

    
  

        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:[000000]

Directory LAUREL$DKA500:[000000]

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 [000000] directories of both cdroms you get:

MOE> dir laurel$dka500:[000000]

Directory LAUREL$DKA500:[000000]

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:[000000]

Directory CURLY$DKA500:[000000]

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:[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.

    
    

    
  
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
Closed: 23 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: