Anal/dis/rep/read

[labadie_1]

Well I do not know.

The example in the doc has files by file-id and file name, with the same lostheader message.

%VERIFY-W-LOSTHEADER, file (16,1,1) []X.X;1
not found in a directory
%VERIFY-W-LOSTHEADER, file (17,1,1) []Y.Y;1
not found in a directory
%VERIFY-W-LOSTHEADER, file (18,1,1) []Z.Z;1
not found in a directory
%VERIFY-W-LOSTHEADER, file (19,1,1) []X.X;2
not found in a directory
%VERIFY-W-LOSTHEADER, file (20,1,1) []Y.Y;2
not found in a directory
%VERIFY-W-LOSTHEADER, file (21,1,1) []Z.;1
not found in a directory
%VERIFY-W-LOSTHEADER, file (22,1,1) []Z.;2
not found in a directory
%VERIFY-W-LOSTHEADER, file (23,1,1) LOGIN.COM;163
not found in a directory
%VERIFY-W-LOSTHEADER, file (24,1,1) MANYACL.COM;1
not found in a directory

Gerard, puzzled

[Ian Miller.]

Re /LIST - according to the manual - lists all files. "If you specify /LIST, the utility produces a file that contains a listing of ALL file identifications (FIDs), file names, and file owners.". Not a particularly useful feature generally.

The original problem is fixed but what you are commenting on now is why the utility did not give the filename as well as the fileid in the original message - is that correct?

[Wim Van den Wyngaert]

Yes Ian. Normally the name is not given if the file is temporary (t.i. already deleted but still open) or spooled (don't know how that works in detail).

Wim

[Hein van den Heuvel]

>>> The example in the doc has files by file-id and file name, with the same lostheader message.

But this topic was not about a 'lostheader'.
It was triggered by the /read telling analyze to read all allocated blocks on the disk.
One of those was bad reporting an IO problem

Wim, I would not expect a bad block to clear over a reboot. If it was in a temp file, and that file was deleted, then analyze would not need to re-read and that could hide the problem.
If after reboot the block is re-used (for an other, or for 'the same' file), then the write operation may actually trigger clearing the problem (relocating the disk block).

>> I recreated debug.exe. No more parity errors now.

As per above... deleting the old file would have been needed to hide it, rewrite to clear it.

>> So, why wasn't the name debug.exe given by anal ?

Good question! Sorry, no answer.

Btw 1... DUMP/HEAD is the only command that does not need file-number + file-id. Just a file number will do.

Btw 2... other then the file name, you may want to use the mapping table in the header to determine whcih physical block was mapped by vbn 325.

Hein.

[Uwe Zessin]

A file that was created through the spooling mechanism is never entered into a directory. It can have a name recorded in the file header anyway - that is why you can see []BLA.DAT;1

When you delete an open file, sometimes just the directory entry is removed - the file header is maked unused when the file is really closed. A 'temporary' file is one that never was entered into a directory - there is an option that can be specified on file CREATE. I am sure the spooling mechanism uses the same feature.

Again, the behaviour of ANALDISK looks like a bug to me. It is very likely that nobody of us can answer your persistent 'why'. You have to talk with the maintainer (HP).

[Bojan Nemec]

Wim,

Sorry for the wrong pipe, I should test it.

My opinion is, that anal reads the indexfile and dir reads the directory. Both files contains the file name and the file id.

So, as Uwe suggested, try to look to the dump/head (this is the dump of the index file). Examine the file name and the back link file (it should point to the directory).

Was that the current sys$share:debug.exe or maybe it was a remaining of some VMS upgrade?

Bojan

[Wim Van den Wyngaert]

Yes it was sys$share. Maybe the name wasn't given because the file was corrupt ?
I will keep an eye on it.

Wim

[Uwe Zessin]

Hm...
Sorry, but that does not sound plausible to me. We're talking about corruption _inside_ a file, not in the file system's structure. If the file is properly linked from a directory I think the full path should be displayed to make the whole handling easy for the user.

[faris_3]

Hi,

You may try to check if you have a problem
on the free blocks now.

Fill the disk

$ copy nl: tempfile /alloc=free_blocks_on_disk

$ set file /end tempfile

$analyze /disk/read ...

hth,
HF

[Wim Van den Wyngaert]

Uwe,

I don't know how the program is written but may be it doesn't always do the effort for looking for the file name after a parity error.

Farris,

Did somethink like that. No extra bad blocks.

All,

Maybe the disk should have been filled in the farris way before the OS was installed. Or maybe we should have used some kind of read check option during install.

Wim