TL;DR don't delete anything out of [SYSLOST] until you are sure there are not alias entries in other directories.
If you don't have DFU or FIND, finding the duplicates is not straight forward. DFU will allow you to find all instances of alias directory entries with the command:
$ dfu directory /alias $1$dga1501:
On a system disks, aliases are expected. That's how sys$common works.
For data disks, they are not common, they won't normally exist unless someone added entries (or hard links on ODS-5).
So you should investigate any aliases that DFU finds.
See help set file/enter and set file/remove
It's too late now, but if you ever have a disk corruption, you should do a backup/physical of it while it is mounted /foreign /nowrite before trying to repair anything, because when you repair, you lose information about what was corrupted.
And before running analyze/disk, turn on bypass priv, otherwise it may not be able to access everything it needs to. For example, some users may set protections to deny System access, although doing so just makes it more likely that someone will see the files. And the first analyze should be an analyze/disk/norepair/lock just to see the extent of the damage. If there was a known corruption, and you don't have a physical backup, you should only mount the disk /nowrite.
Ok, dire warnings out of the way, let's proceed to what you should do to fix the problem.
First some background about how the queuing database stored files. It stores the name and the file id. When it displays the entries, it calls lib$fid_to_name to display the path (or something that behaves like lib$fid_to_name).
If you do a show entry /ful the file name specified will be in unconcealed lib$fid_to_file format, e.g. for the entry if the back link was correct, the file would show up as
File: _$1$DGA1501:[PROJECT.JOBS]TEST1_CODE.COM;6
instead of
File: _$1$DGA1501:[SYSLOST.PROJECT.JOBS]TEST1_CODE.COM;6
as it does now, but it would never show up as
File: ROOT$PROJECT:[JOBS]TEST1_CODE.COM;6
It seems unlikely the the original definition of ROOT$PROJECT was:
"PROJECT$ROOT" [exec] = "SAN$ROOT:[PROJECT.]" [concealed] (LNM$SYSTEM_TABLE).
I think it is more likely that it was:
"PROJECT$ROOT" [exec] = "SAN$ROOT:[TEMPREGION.PROJECT.]" [concealed] (LNM$SYSTEM_TABLE).
My guess is that the [000000]TEMPREGION.DIR got clobbered, and when you did the analyze/disk/repair the backlink of the PROJECT.DIR file got "fixed" to point to [SYSLOST]
Is there a [000000]TEMPREGION.DIR;1 file?
What dates are displayed for the [000000]*.dir files?
$ directory/size=all/date/width=(file:38,size:8)/date=(cre,mod,bac) $1$dga1501:[000000]*.dir
What is displayed if you enter the commands:
$ pipe dump/header/block=(s:1,c:0) project$root:[jobs]test1_code.com;6 | search/nowin sys$pipe "back link","file name"
$ pipe dump/header/block=(s:1,c:0) $1$dga1501:[project]job.dir | search/nowin sys$pipe "back link","file name"
$ pipe dump/header/block=(s:1,c:0) $1$dga1501:[syslost.project]job.dir | search/nowin sys$pipe "back link","file name"
$ pipe dump/header/block=(s:1,c:0) $1$dga1501:[syslost]project.dir | search/nowin sys$pipe "back link","file name"
$ pipe dump/header/block=(s:1,c:0) $1$dga1501:[000000]syslost.dir | search/nowin sys$pipe "back link","file name"
The best documentation about ODS-2 is VMS File System Internals, by Kirby McCoy, but it is long out of print and not easy to find. Here's a link I just found with a text file written by Andy Goldstein in 1985 "Files-11 On-Disk Structure Specification"
https://web-docs.gsi.de/~kraemer/COLLEC ... S/ods2.txt
Every directory file has a "back link" to a single "primary" directory that it is cataloged in. If you delete a directory (i.e. set it to /nodirectory, then set protection to delete, then delete it), all the files that were in that directory will now be lost, i.e. there is no path from the root [000000] master file directory to the files. Analyze/disk/repair scans the index file (which contains all the file headers) and verifies that directory contained in the back link is valid, if not it creates a directory entry in the [syslost] directory and resets the backlink in the file header to the syslost directory.
You can probably "fix" this by turning on bypass priv, and renaming [syslost]project.dir [000000]project.dir if the project directory really was in the [000000] directory to begin with.
But before doing anything more, it would be best to make a physical backup of the disk (while is is mounted foreign, you don't want changes being made to the disk while it mounted read/write). Then at least you have a "bit for bit" copy of the disk as it is now.
