Is there a utility to open and display/copy a file via FILE ID?

[John Gillings]

Aha ODS-5 - that's why I couldn't make it work! I didn't think Derek would give us a bum steer ;-)

[Derek Garson]

Right. I overlooked that that feature (FID abbreviation) is ODS-5-only, as it worked for me.

I guess that is for compatibility as much as anything else. I can't see any specific reason why the FID syntax doesn't make sense on ODS-2. It's just that you never need it because file specs can't be too long.

As far as the original problem goes I was really hoping that

DDcu:[0,0,0]~[x,y,z]

would do the trick. It should almost work since 0 in the DID field in a NAM/FIB would suppress the directory lookup and just allow access by FID. (-: But, no.

As Hein says, that would then require yet another special case with file spec defaulting.

[Tom O'Toole]

Thanks for the info Derek, I can't apply it to this specific case, but I was not aware of that little trick, you learn something every day. Also learned you can reopen a thread.

As a followup, I'm using the example code Hein posted, which is perfect for my application. Thank you!!

[Jess Goodman]

Another good reason that FID-only file specifications are not allowed for any RMS file reference is that it would bypass any permission restrictions on the directory. Even if this was only allowed with a privilege such as BYPASS it would still skip any security auditing set on the directory.

However I just did a test on my VMS 7.3-2 (fully patched) system and was surprised to see that you can skip the directory protection check on any outer directories by using a DID-abbreviation to point directly to an unprotected sub-directory.


$ DIRE/PROT/FI DISK$SAN016:[000000]ODS5TEST,[ODS5TEST]sub

Directory DISK$SAN016:[000000]

ODS5TEST.DIR;1 (2547,1,0) (RWED,RWE,RWE,)

Total of 1 file.

Directory DISK$SAN016:[ODS5TEST]

sub.DIR;1 (2620,7,0) (RWE,RWE,RWE,RE)

Total of 1 file.

Grand total of 2 directories, 2 files.
$ SET PROCESS/PRIV=NOALL

$ COPY DISK$SAN016:[ODS5TEST.sub]JUNK.TXT;1 NL:/LOG
%COPY-E-OPENIN, error opening DISK$SAN016:[ODS5TEST.SUB]JUNK.TXT;1 as input
-RMS-E-PRV, insufficient privilege or file protection violation

$ COPY DISK$SAN016:[2620,7,0]JUNK.TXT NL:/LOG
%COPY-S-COPIED, DISK$SAN016:[2620,7,0]JUNK.TXT;1 copied to NL: (1 record)

Other commands that access the file this way seem to work too, with a notable exception:
$ TYPE DISK$SAN016:[2620,7,0]JUNK.TXT
%TYPE-F-SYSERROR, system service error
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

But the strangest result from my tests is that using the DID-abreviation path to get to JUNK.TXT works with the DUMP command, but using JUNK.TXT's file ID with DUMP's /ID= qualifer does not work. I think this is because TYPE and DUMP /ID both use the back link file identification to get the full path to the file.

[Hein van den Heuvel]

>> Another good reason that FID-only file specifications are not allowed for any RMS file reference is that it would bypass any permission restrictions on the directory.

I beg to differ.

All a directory does is to provide a name to FID translation. If you _know_ the FID, then clearly the directory protection is irrelevant.

The object (file) protection is the only thing that really matters. Directory protection is just a minor 'hurdle' / inconvenience to stop simple undesired access attempts.

One could conceivably just brutefoce your way through all ID/SEQ combination and nothing would stop you. Only resource consumption would conspiciously high.

You could argue that when you know the FID, the directory protection should allow/prohit you from back-translating to a name, which it is indeed doing.

>> Even if this was only allowed with a privilege such as BYPASS it would still skip any security auditing set on the directory.

bah humbug. Only the object protection reallly matter. SYS$OPEN and SYS$QIO have full support for open by file ID.

>> $ TYPE DISK$SAN016:[2620,7,0]JUNK.TXT
%TYPE-F-SYSERROR, system service error
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

Hmmm intersting.


>> DUMP's /ID= qualifer does not work. I think this is because TYPE and DUMP /ID both use the back link file identification to get the full path to the file.

Yeah... and IMHO that is a big and annoying bug. The LIB$FID_TO_NAME call used by DUMP should be use in an advisory and thus optional role. It should not break the main function as it does today.


Cheers,
Hein.

[Tom O'Toole]

Yeah, the undocumented dump/id was one of the first things I tried, but it dosn't do what I had hoped at all.

Besides, after entering a filename, I can do anything, not just dump it.

[Tom O'Toole]

Of course, if it's a choice between fixing a bug in an undocumented function of dump, and increasing the maximum tape blocksize, you know where my vote goes.

[Jess Goodman]

Actually the DUMP /ID= feature has been documented since at least VMS 7.2.

[Jon Pinkley]

Here's a summarized demo showing that directory protection is only protecting the file names/file id (and to an extent, the ability to delete a file, for example, I wasn't able to delete the file using DFU's delete by file/id. See attachment for more complete example.

You can easilty replace the contents of the file if you have write access to it, regardless of the protection of the primary directory the entry is in.


OT$ cre /dir [.protected]
OT$ set default [.protected]
OT$ cre file_with_world_access.txt
This file is in a protected directory, but the file has w:rwed
Exit
OT$ set prot=w:rwed FILE_WITH_WORLD_ACCESS.TXT;1
OT$ set def [-]
OT$ set prot=(g,w) protected.dir;1

From non-prived account:

TSTO:[PINKLEY_1]> type ROOT$USERS:[JON.protected]FILE_WITH_WORLD_ACCESS.TXT;1
%TYPE-W-SEARCHFAIL, error searching for ROOT$USERS:[JON.PROTECTED]FILE_WITH_WORLD_ACCESS.TXT;1
-RMS-E-PRV, insufficient privilege or file protection violation
TSTO:[PINKLEY_1]> cre /dir [.play]
TSTO:[PINKLEY_1]> set def [.play]
TSTO:[PINKLEY_1]> file jonsfile.txt/fid=(58964,79,0)
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
TSTO:[PINKLEY_1]> type jonsfile.txt
This file is in a protected directory, but the file has w:rwed
TSTO:[PINKLEY_1]> type jonsfile.txt
This file is in a protected directory, but the file has w:rwed
TSTO:[PINKLEY_1]> crea new.txt
This will replace contents of original file.
Exit
TSTO:[PINKLEY_1]> copy/over new.txt jonsfile.txt
%COPY-I-OVERLAY, ROOT$USERS:[PINKLEY.PLAY]JONSFILE.TXT;1 being overwritten
%COPY-S-COPIED, ROOT$USERS:[PINKLEY.PLAY]NEW.TXT;1 copied to ROOT$USERS:[PINKLEY.PLAY]JONSFILE.TXT;1 (1 block)
TSTO:[PINKLEY_1]> type jonsfile.txt
This will replace contents of original file.
TSTO:[PINKLEY_1]> log
PINKLEY logged out at 25-JUN-2008 13:51:53.53
%HGLOGIN-I-EXIT, returning to original JON session
OT$ type [.protected]FILE_WITH_WORLD_ACCESS.TXT;1
This will replace contents of original file.
OT$

[John Gillings]

Tom,

If you want to avoid making a directory entry, and what you're attempting to recover is text, and you have heavy privileges, you can use DUMP, but it's rather round about... (a procedure to automate this is feasible, but it involves a lot of parsing).

In this example I have a file called "JUNK.TXT" with FID (16193,2,0) on physical device $1$DGA6298:

First (SYSPRV or BYPASS required) access the header of the file using DUMP. This requires the "magic" INDEXF.SYS FID offset - this is used to calculate the block in INDEXF.SYS containing the header. There's a formula based on maximum files allowed and cluster size, but for one-off use, the simplest method is to dump the block of your FID, see what FID is returned and use the difference as your offset. In my case

$ dump/file/block=(s:16193,c:1) $1$DGA6298:[000000]indexf.sys

gives me:
File identification: (15907,3,0)

So calculate my target block as:

16193*2-15907 = 16479

$ dump/file/block=(s:16479,c:1) $1$DGA6298:[000000]indexf.sys

Sanity check the FID, backlink and name.

File identification: (16193,2,0)
...
Back link file identification: (0,0,0)
...
Identification area
File name: JUNK.TXT;1

FID is correct, backlink is (0,0,0), meaning "lost" and filename is as I expect.

Now look at the map area:

Map area
Retrieval pointers
Count: 41 LBN: 9430

With LOG_IO privilege, the extents can be dumped by dumping LBNs from the device. I won't dump out the whole cluster, since I know there's only one record in the file.

$ dump/block=(s:9430,c:1) $1$DGA6298:
Dump of device $1$DGA6298: on 26-JUN-2008 07:57:59.79

Logical block number 9430 (000024D6), 512 (0200) bytes

00000000 0000FFFF 00747874 2E6B6E75 6A206E69 20747865 7420656D 6F730015 ..some text in junk.txt......... 000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000020
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000040
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000060
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000080
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000A0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000C0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000E0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000100
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000120
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000140
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000160
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000180
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001A0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001C0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001E0
$

Obviously this will get complex if there are many extents and/or extension headers. You also need to interpret the dumped output to reconstruct records.

However, if all you want to do is visually inspect the contents of the file, it might avoid the need to write a program to create a directory entry.