Disk showing file+size but type results in file not found

[Midrange-EB]

Hello,

after an error on one of the shadowmembers the disk started behaving perculiar.

For example when I do a dir listing it shows:

$ dir bhr_save:secur*

Directory BHR_ROOT:[SAVE]

SECURITY.20070830;1 26/36 31-AUG-2007 00:31:00.62

However when I would like to type or edit it produces:

$ type bhr_save:SECURITY.20070830
%TYPE-W-SEARCHFAIL, error searching for BHR_ROOT:[SAVE]SECURITY.20070830;
-RMS-E-FNF, file not found

An analyze/disk/repair doesn't help so I guess I'm out options and thus restoring a backup would be the only way out, or am I overlooking something?

Thanks!

[Heinz W Genhart]

Hi Midrange-EB

first of all, Welcome to the ITRC OpenVMS forum.

What Version of OpenVMS ist this?

Is your problem disk a ODS-2 or an ODS-5 Disk?
(SHOW DEVICE/FULL disk)

If this disk is a ODS-5 Disk, did you a
$SET PROCESS /PARSE_STYLE=EXTENDED ?

Regards

Geni

[Karl Rohwedder]

How is the logical bhr_root defined (sh log/fu bhr_root)?

regards kalle

[Hein van den Heuvel]

Geni,
There's nothing extended or ods-5-ish about the file name it there now?

Kalle,
It seems that 'bhr_root' can be used just fine for Directory no?

Midrange-EB,
If DIRECTORY can display the size, then the file name in the directory, leads to the file-header (through the file-id) where the size is kept. For there it is only a small step to the actual data: read the mapping pointer in that same header, and follow that to the data.
Could the file have an EXTENTION header which can not be found? That's unlikely because there are at most two entries needed as 26/36 suggests a cluster size of either 18 or 36.

Anyway, you should DUMP/HEADER/BLOCK=COUNT=1 for the next step of the investigation. Post the results here (in an attachment as a text file if that dump works).
Look at the FILE-ID (dir/fi).
Now try a DUMP/HEAD memberX:/ID=id-part for both members. Header the same?
Now figure out the LBN for the header (combine ID, Cluster-size, Max-files) and $DUMP/BLOC=(COUN=1,STA=) memberX:.
DO that for each member and compare the bits.. they should be the same.

>>> after an error on one of the shadowmembers the disk started behaving perculiar

Host-based? - what OpenVMS version/patched?
Controller based? Which controller? Version?

Anyway what was done after the error? Did the shadowing reject the drive? Was the disk reporting errors replaced?

It is not unheard of that a shadow set for which a member went bad gives 'unexplainable' results because the members are out of sync.
I'd like to think that the shadowing resolves that, but unfortunately judging by the data alone shadowing can not on its own decide what is good, what bad. It may seem obvious to us, but a 'bad' result may be the correct data as far as the system is concerned (unlikely though!).

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Midrange-EB]

Thanks for your replies.

All this is on VMS 7.3.2
ODS-2
HSZ-80 controller/cabinet

A dump of the header also leads to a file not found message.

I will dig some deeper tomorrow.

Thanks so far.
Jeroen.

[Hein van den Heuvel]

Jeroen,

Maybe the DIR/SIZE info was still coming from the system caches. Is that still working, or does that also give FNF?

Here is a little script to dump the raw 'supposed' file header as VBN from INDEXF.SYS. It implements the algoritme needed which I hinted to above.

Use black bible 'VMS File systems internals' or SYS$LIBRARY:LIB.MLB to decode :-).

Met vriendelijke groetjes,
Hein.



$ type DUMP_FILE_HEADER.COM
$!
$! read_file_header.com Hein van den Heuvel, Sep-2007
$!
$! This command file dumps the header for a file, from INDEXF.SYS using the file-id.
$! Next step might be to not translate that to an LBN to be able to directly read it from an unmounted (shadow) copy.
$!
$!
$! Enjoy!
$! Hein
$! HvdH Performance Consulting
$
$!
$! 1) Get file id from directory commands
$! F$file(file,"FID") might get 'locked' or 'file-not-found' error)
$!
$if p1.eqs."" then inquire p1 "file name"
$dir/file/out=tmp.tmp/notrail/nohead/wid=file=1 'p1
$open/read tmp tmp.tmp
$read tmp tmp
$read tmp tmp
$clos tmp
$dele tmp.tmp.
$id = f$elem(0,",",f$elem(1,"(",tmp))
$
$!
$! 2) Use file Id to look up file corresponding file header in INDEXF.SYS
$!
$dev = f$parse(p1,,,"device")
$!
$! The file-ID is an offest into INDEXF.SYS
$! INDEX.SYS first starts out with 4 cluster, and then
$! a bitmap to hold a bit for each potential file header.
$! And as for every VBN, the count starts at # 1.
$!
$indexf_bitmap_vbn = (f$getdvi(dev,"cluster") * 4) + 1
$ibmapsize = (f$getdvi(dev,"maxfiles") + 4095) / 4096
$header_vbn = indexf_bitmap_vbn + ibmapsize + id -1
$dump/block=(count=1,start='header_vbn') 'dev'[000000]indexf.sys
$exit

[Thomas Ritter]

EB,
Are the results the same when you

$ type bhr_root:[save]security.20070830
And
$ type bhr_save:security.20070830

If you get the chance would you run

$ anal/disk/repair/lock â diskâ

And post the results.

[John Gillings]

Wildcards can sometimes help work out what's missing. Try

$ TYPE/PAGE bhr_save:secur*.*

I'd also look at DIR/FULL to see if ther are any clues there.

[Willem Grooters]

This rings a bell, I've seen this before, and IIRC, my investigation at the time lead to the following conclusion:

If a concealed logical (read: logical device) is a searchlist of one directory over multiple physical disks, and the file is on the second-mentioned disk, DIR will find it but direct acccess to the file will fail.
Accessing the file EXPLICTLY by the real location (so the second path in the list) will allow you to access the file.

This happened because the physical disk on which the second entry in this serachlist was full and the directory was kind of 'extended' on the other disk using a searchlist.

Example:
BHR_ROOT was DISK1:[BHR.](conc), contains a directory [SAVE] where your file (SECURITY.20070830;1 resides.
Now you change BHR_ROOT to be:
DISk2:[BHR.](conc), DISK1:[BHR.](conc), and on DISK2:[BHR] you create a [SAVE] directory to store new files.
DIR BHR_ROOT:[SAVE] will show up your file, but TYPE will fail to get it. if you access the file by it's real directory DISK2:[BHR.SAVE], you'll get it.

The problem was solved by relocation the whole directory from the full disk to the empty one, thereby removing the split over devices of that directory.

[Wim Van den Wyngaert]

Willem,

I have a search list on 3 disks (a concealed device) and it behaves normally.

Wim