- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Is there a utility to open and display/copy a ...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-24-2008 08:46 PM
тАО06-24-2008 08:46 PM
Re: Is there a utility to open and display/copy a file via FILE ID?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-24-2008 09:43 PM
тАО06-24-2008 09:43 PM
Re: Is there a utility to open and display/copy a file via FILE ID?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-25-2008 08:20 AM
тАО06-25-2008 08:20 AM
Re: Is there a utility to open and display/copy a file via FILE ID?
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!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-25-2008 08:29 AM
тАО06-25-2008 08:29 AM
Re: Is there a utility to open and display/copy a file via FILE ID?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-25-2008 08:45 AM
тАО06-25-2008 08:45 AM
Re: Is there a utility to open and display/copy a file via FILE ID?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-25-2008 08:55 AM
тАО06-25-2008 08:55 AM
Re: Is there a utility to open and display/copy a file via FILE ID?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-25-2008 08:56 AM
тАО06-25-2008 08:56 AM
Re: Is there a utility to open and display/copy a file via FILE ID?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-25-2008 09:09 AM
тАО06-25-2008 09:09 AM
Re: Is there a utility to open and display/copy a file via FILE ID?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-25-2008 10:13 AM
тАО06-25-2008 10:13 AM
Re: Is there a utility to open and display/copy a file via FILE ID?
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$
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-25-2008 02:03 PM
тАО06-25-2008 02:03 PM
Re: Is there a utility to open and display/copy a file via FILE ID?
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.