Duplicate directory name - same version

[LM_2]

Has anyone seen anything like this - I know it is extremely odd:

LISA_1> dir robinson.dir;*

Directory VICDATAEDI:[EDI]

ROBINSON.DIR;1 ROBINSON.DIR;1 ROBINSON.DIR;1


I have three directories with the same name and the same version number. When I do a directory on this disk, it goes in an endless loop and never quits and I found that I have the above problem. I am not sure how to fix this or what to do....??

The directory has data within it and I do not want to delete it cause I need it. I tried to do an analyze/disk/repair and I get this error:

%ANALDISK-W-BAD_NAMEORDER, filename ordering incorrect in VBN 45
of directory VICDATAEDI.EDI (5132,1,1)
Filenames are ROB_COMP.TRNNSON.DIRHG_LOG.DIR
%ANALDISK-W-BAD_NAMEORDER, filename ordering incorrect in VBN 50
of directory VICDATAEDI.EDI (5132,1,1)
Filenames are SEARCH.TECVE_SETS.DIRG_LOG.DIR

Which looks like a bunch of garbage. Anyone know what I can do? I tried to copy everything from the Robinson.dir to robinsonx.dir but the problem exists when I copy it into a new one. It's a huge directory with important data in it so I can't delete it. Help!!

[David Jones_21 · Accepted solution]

What fileids do you get if you do a directory/file_id robinson.dir;*? This will tell you whether you actually have different directory files or it is just the EDI.DIR file that is corrupted.

I'd try to rename robinson.dir; to xrobinson.dir; to see if that would separate the entries.

[LM_2]

Directory VICDATAEDI:[EDI]

ROBINSON.DIR;1 (61778,1,0)
ROBINSON.DIR;1 (61778,1,0)
ROBINSON.DIR;1 (3992,75,0)

[LM_2]

LISA_1> directory/file_id *robinson.dir

Directory VICDATAEDI:[EDI]

ROBINSON.DIR;1 (61778,1,0)
ROBINSON.DIR;1 (3992,75,0)
XROBINSON.DIR;1 (61778,1,0)

[Steven Schweda]

That certainly looks like a mess.

Can we assume that "VICDATAEDI" is just a
simple logical name for a real disk?

I believe that the usual latst-ditch cure for
this sort of thing is:

1. Make sure that (if it exists) [SYSLOST] on
that disk is empty.

2. Use SET FILE /NODIRECTORY ("Use with
extreme caution.") on all the bad
directory files. This may include all the
*ROBINSON*.DIR files and also EDI.DIR.

3. Delete all the bad directory files.

4. Use ANAL /DISK /REPA to put all the (now)
lost files into [SYSLOST] (and to fix any
remaining disk structure errors).

5. Create some new (healthy) directories,
and move the files from [SYSLOST] to the new
(healthy) directories. (This may be easy or
difficult, depending on how much directory
structure had to be destroyed, and how many
files need to be put into how many different places.)

See HELP SET FILE /NODIRECTORY for
reassurance (or something).

To play things safe, you might wish to do a
BACKUP /PHYSICAL (/VERIFY) on that disk
before wrecking everything. That way, you
should be able to get back to the existing
mess when it all goes wrong.

[Hein van den Heuvel]

Goood advice Steve.

Additional points.

1) Do a DUMP/DIRECTORY into a file for potential future analysis

2) It is probably just a a problem wit EDI.DIR for not. How large is it?

3) After the SET /NODIR make a COPY of the ex-directory EDI.DIR again for further analysis.

4) Indeed make sure SYSLOST was empty. The you can either rename is to EDI.DIR or it's contents into a fresh EDI.DIR

Hein.

[Jan van den Ende]

Lisa,

Setven gave some sound advise, but before you start with all that work, please post a
$ SHOW LOGICAL VICDATAEDI /FULL

It is entirely possible that your directory is indeed corrupt, but is _IS_ possible to generate the same symptoms by defining VICDATAEDI as a CONCEALED searchlist.
Since your renamed dir has the same ID, you would also need to have alias names ("SET FILE/ENTER=.."), but if this system is NOT set up by tourself, it IS worth checking!

Success!

Proost.

Have one on me.

jpe

[Robert Gezelter]

Lisa,

I concur with Jan. Please verify the contents of the logical name before going further.

If the directory files indeed have different FILE IDs (displayed using DIRECTORY/FILE_ID) then it is simply a matter of renamng one of the directories.

If you have shadowing on this drive, I would recommend adding a member to the shadow set, allowing it to come into synchronization, and then disconnecting it. Then privately mount the COPY of the volume and work with it. If something happens, you have not damaged the original.

Pardon my extreme caution, but you did mention that the data in the directory was important.

If I can be of assistance, please let me know.

- Bob Gezelter, http://www.rlgsc.com

[LM_2]

LISA_1> SHOW LOGICAL VICDATAEDI /FULL
"VICDATAEDI" [exec] = "$1$DKD202:[VICDATAEDI.]" [concealed] (LNM$SYSTEM_TABLE)


The data in this directory is extremely important and there is a lot of files within this directory - I have 32 directories beneath edi. It is all of the edi information we have received and processed.

[LM_2]

also - no shadowing setup on this drive.

[Jan van den Ende]

So,

no concealed searchlist.

Next try: you renamed one of the ROBINSON.DIR to XROBINSON

What is the result of

$ DIR VICDATAEDI:[EDI.XROBINSON]

If somehow you have directory aliasses that you lost track of, this COULD reveal it.

If this does not give sensible results, then I as far as I know, you ARE down to Steven's solution.

Proost.

Have one on me.

jpe

[Robert_Boyd]

Before proceeding with any repairs please be sure you have all of the latest patch kits installed for VERIFY, BACKUP and/or XFC, RMS, etc that might have some bearing on the file system integrity.

I agree with all of the suggestions you have so far -- it certainly sounds like at least 1 backlink pointer somewhere has gotten trashed.

Best wishes with repairing the situation.

If you're able to use COPY or BACKUP to safeguard the data to another location before proceeding that might give you more confidence in the eventual outcome.

Robert

[Heinz W Genhart]

Hi Lisa

we had exactly same problem last year on one of our production clusters (2 AS 8400 with OpenVMS 7.3-2).

We corrected the problem by copying the whole disk (without the suspect directories) to another disk, this because we was not sure that it is not a disk (XP-SAN) problem.

Some days later we had the problem again. We assumed, that somebody does something very wrong, like open the directoy files one level higher and write something into it. We found also a DFU image on the systemdisk. I deleted DFU this time.

We assumed also that the application does something abnormal. Finnaly we enabled auditing on this system for every user (Its extremly cpu and I/O intensive !!!) and we informed the users and the application programmers as well, that we switched on a 'supervising tool'.

.... and it happened never again. But unfortunately we never found out the cause of the problem until now, but I think somebody who did something abnormaly, stopped to do it.

We did not install patches and we did not change something else on this system.

Best regards

Heinz

[David Jones_21]

"LISA_1> directory/file_id *robinson.dir

Directory VICDATAEDI:[EDI]

ROBINSON.DIR;1 (61778,1,0)
ROBINSON.DIR;1 (3992,75,0)
XROBINSON.DIR;1 (61778,1,0)"

I'd do another rename of robinson.DIR; to yrobinson.DIR just to make sure you have 3 unique directory entries, then set xrobinson.DIR/nodirectory and delete it. Finally, merge [.robinson] and [.yrobinson], but watch for duplicate files.

I imagine the bug that causes this came in with the change to support case-sensitive filenames.

[LM_2]

After I renamed the robinson.dir to xrobinson.dir - I had two robinson.dir;1 and one xrobinson.dir - I tried to rename the other robinson.dir- but it said it did not exist. But when I did a dir *robinson.dir - it showed all three. So I don't know what to do anymore. It looks like it is there - but I can't access it.

[Robert Gezelter]

Lisa,

First, take your time. If the two directories have different File IDs, they can be referenced via the File IDs (ok, it potentially involves some code, but it is not too bad).

Since production data is involved, I recommend extreme caution. If worst comes to worst, the directories can be deleted and the files recovered, but that may lose the filenames (not the files) in some cases. When there is doubt about the contents of the index file, I often recommend that clients use ANALYZE/DISK/LIST to get a listing of the Index File itself. A BACKUP/PHYSICAL of the drive in question is certainly a good idea.

Above all caution is highly recommended. I have seen more clients lose data during the recovery than at other times. This is recoverable, but it requires caution. If you would like to speak about this offline, please contact me via my www site.

- Bob Gezelter, http://www.rlgsc.com

[Hein van den Heuvel]

Guys, read the base topic carefully. Most of the suggestions made here are nixed by the initial description: "filename ordering incorrect"... do you really think that might be a search list problem? No.


Lisa, Don't worry too much about the corrupted directory. The files, and the data in them will be there just fine.

You should worry a little about how this might have happened, and whether next time you might not be so lucky that it is 'just' a directory but that actuall data has a problem.

I think you'll be fine with just SET FILE/NODIR. But don't delete the directory, just rename it if you like. While there is not official SET FIL/DIR command, I have a tool on the VMS FREEWARE, RMS_TOOLS to do so.

There is still one alternative to ANAL/DISK and SYSLOST which you might want to do before the ANAL/DISK. After you 'undirectoried' and renamed EDI.DIR to EDI.broken you can make a fresh EDI.DIR and perform a SET FILE/ENT on all the files that you know should be in there. You can use DIR/FI... untill the break point, and DUMP/DIR for the data beyond there.

It shouldn't be too hard to automate that with a DCL or PERL script.

Good luck,
Hein.

[Galen Tackett]

DFU might actually be able to help. It does have a command to rebuild directories. If you have DFU installed try:

$ DFU ! or RUN SYS$SYSTEM:DFU
DFU> HELP DIR/RECOVER

I recently had a problem with a scrambled directory which listed two or three file several times and was not sorted correctly either.

DFU made it easier than doing ANALYZE/DISK, SET FILE/NODIR, DELETE xxx.DIR, ANALYZE/DISK, and looking for everything in [SYSLOST]. DFU managed to get the files back in the right directory without having to go thru [SYSLOST]first.

HOWEVER: DFU's help does have a caution about using DIR/RECOVER on critical system directories!

[LM_2]

Where do I get dfu...? This is a highly used area and I have so many files within this directory and all of the sub directories. I am in the process of setting up a new cluster which will make my old cluster go away - so I will test some of this out within my new system and getit working properly before I go live.

Does anyone see a problem with keeping it how it is for now - or will I run into more problems with leaving it the way it is for now?

[Jan van den Ende]

Lisa,

DFU is on the VMS Freeware CD that comes with the VMS distribution.

hth

Proost.

Have one on me.

jpe

[Robert Gezelter]

Lisa,

I cannot predict the future, but my general experience with file system problems is that they should be corrected at the earliest opportunity. Haste is dangerous, but deferral can be worse.

Data (including file systems) problems tend to cascade, with ever increasing damages. The classic "disk structure" emergency involves a situation with a corruption in the storage allocation, where blocks are included in multiple files. In that case, it is advisable to take the volume immediately out of service and sort out what happened.

In your case, I would not advise the same degree of haste, but I would deal with it promptly, while it can be a scheduled activity, rather than a emergency crisis response when something vital to your organization is impacted.

- Bob Gezelter, http://www.rlgsc.com

[LM_2]

The only reason I am asking if this is a hot issue is because if you look at the dates on the directory files - two are from 1999 and one is from 2003 so these are old problems that I just came across.

Directory VICDATAEDI:[EDI]

ROBINSON.DIR;1 4 24-OCT-1999 13:41:04.08
ROBINSON.DIR;1 4 24-OCT-1999 13:41:04.08
ROBINSON.DIR;1 1 18-JUN-2003 12:36:03.04

[Robert Gezelter]

Lisa,

I see that. My concern is based on several rather spectacular episodes I have observed at client sites (having a practice that deals with these issues create a steak stream of often not disclosable situations).

In one case, a site discovered that their backups were not usable. The investigation revealed that this had, apparently, been the situation for quite some time, but nobody had tried an emergency restore. The problem came to light when a major storage malfunction rendered the shadow copies damaged. The after effects were not pleasant.

I am not saying that this is as severe, but since we do not know the details of how this happened, or what its true side effects and implications may be, if you were my client, I would recommend that, at a minimum we:
- preserve the volume (using BACKUP/PHYSICAL or a forensic-quality imaging utility) and
- identify precisely what happened and how we can fix it.

Since these are vital data files, and the situation is longstanding, I would not recommend simply hitting it with various utilities. There is too much risk involved for that.

My US $0.02.

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Lisa,

My apologies for a typo. In my previous posting, "... steak stream ..." should have been "... steady stream ...".

- Bob Gezelter, http://www.rlgsc.com

[LM_2]

I just did an analyze/disk and at the end of the log I had some more info:
%ANALDISK-W-BAD_NAMEORDER, filename ordering incorrect in VBN 45 of directory VICDATAEDI.EDI (5132,1,1) Fil
%ANALDISK-W-BAD_NAMEORDER, filename ordering incorrect in VBN 50 of directory VICDATAEDI.EDI (5132,1,1) Fil
%ANALDISK-W-BADHEADER, file (1741,220,1) invalid file header
-ANALDISK-I-BAD_FIDSEQ, unexpected FID_SEQ field
%ANALDISK-W-BADHEADER, file (55211,402,1) invalid file header
-ANALDISK-I-BAD_FIDSEQ, unexpected FID_SEQ field
%ANALDISK-W-FREESPADRIFT, free block count of 2883753 is incorrect (RVN 1); the correct value is 2882925


Is this more info - or pretty much the same info I had with my analzye/disk/repair...?