BAD file version on file LMIATRN.DAT;429496729

[Benito Salinas_1]

Hello,
A developer mistakenly placed a file with an extension of ;429496729
Now, I can not delete it and can not seem to view other files after it...??
Can not delete it, copy it, rename it, etc.
Some of the errors are:
RENAME LMIATRN.DAT;4294967295 LMIATRN.DAT;456
%RENAME-E-SEARCHFAIL, error searching for LMIATRN.DAT;4294967295
-RMS-F-VER, error in version number

AND

dir lmiat*

Directory [BANJOBS.GURJOBS.PROD]

LMIATRN.DAT;272 1KB 21-APR-2009 17:10:39.90 (RWED,RWED,RE,)
LMIATRN.DAT;271 20KB 20-APR-2009 17:20:22.85 (RWED,RWED,RE,)
LMIATRN.DAT;270 19KB 17-APR-2009 18:16:18.15 (RWED,RWED,RE,)
LMIATRN.DAT;269 28KB 16-APR-2009 17:18:09.51 (RWED,RWED,RE,)
LMIATRN.DAT;4294967295
no such file
%DIRECT-E-OPENIN, error opening MUPPET_USERS:[BANJOBS.GURJOBS.PROD]LMIAT*.*;* as input
-RMS-E-FND, ACP file or directory lookup failed
-SYSTEM-W-BADIRECTORY, bad directory file forma


Any help is appreciated.

[Jim_McKinney]

See what

$ ANALYZE/DISK MUPPET_USERS:

reports and then, depending upon what sort of issues the volume has, a /REPAIR on the same command (at a time when file operations are unlikely) might help. If you're not familiar with the like of this then post the output of the ANALYZE here and wait for advice.

[Jim_McKinney]

Given what you've posted thus far it appears that PROD.DIR is scrambled. If all you expect to find in it are those first 4 files listed then you may be able to rename them out of the directory, delete the directory, re-create the directory, and rename the files back.

[Hoff]

My first stop would not be ITRC and posting this question here, I'd be standing at that developer's desk seeking an explanation of what was done, and how, and when, and with what tools and what privileges.

Why? It's exceedingly difficult to get into this state in the file system without a directory corruption, a disk corruption, or a developer that has done something very, very, very bad.

If this file was explicitly created by a developer, I'd be resolving that matter first.

And yes, ANALYZE /DISK /REPAIR and similar such can usually clear these cases.

Also ensure your disk not throwing errors, and you have a good archive of your data, and consider (if you're not shadowed) RAID or host-based volume shadowing. Also confirm your ECOs are current for whatever OpeNVMS version is in use here.

But if you have developers that are somehow creating corruptions such as this one, then your whole storage environment is at risk.

[Hein van den Heuvel]

This could be a first visible aspect of a larger directory corruption, but it could also simply be one version number magically flipped to -1, which would be o big deal right?
It would be interesting to know how it got there of course.

A couple of renames should square this away.
You may want to rename away the 'good' ones first, due to the place in the list it is.

Silly example:

$ dir/file [.tmp]
A.TMP;3 (14911,21,0)
A.TMP;2 (14910,54,0)
A.TMP;1 (14822,81,0)
$ open/read/write tmp tmp.dir
$ read tmp rec
$ bad = (5 + f$cvui(3*8,8,rec)).and.-2 ! Name length + offset + round-up to word
$ write sys$output f$cvui(bad*8,2*8,rec) ! Ready?
3
$ rec[bad*8,2*8]=-1 ! Aim
$ write/update tmp rec ! Fire
$ close tmp
$ dir/file [.tmp]
A.TMP;4294967295 (14911,21,0)
A.TMP;2 (14910,54,0)
A.TMP;1 (14822,81,0)
$ set def [.tmp]
$ rena a.tmp; x.tmp;1 /log
%RENAME-I-RENAMED, A.TMP;-1 renamed to X.TMP;1
$ renam x.tmp a.tmp/log
%RENAME-I-RENAMED, X.TMP;1 renamed to A.TMP;3
$ dir/file
A.TMP;3 (14911,21,0)
A.TMP;2 (14910,54,0)
A.TMP;1 (14822,81,0)


Enjoy,
Hein.

[Hein van den Heuvel]

If you wanted to repair that record, then you can use a technique simlir to the one I used to fix it.

Find the record number:
$sea/num/form=non prod.dir LMIATRN.DAT) --> x
The look at it:
$DUMP/REC=(COU=1,STA=x) to visualize the record in question.
Look for the 272,271,270.. as 0110,010F,010E...

Is the corrupted element the last?
Then you can address it with:

$ open/read/write/share=write tmp prod.dir
$ read tmp rec ! Repeat until on target.
$ rec[f$len(rec)-8)*8,16] = 268
$ write /update/symbol tmp rec
$ close tmp

Or just count down the offset from the dump.

Hein.