Re: Divining the full pathname of a file, all logicals translated
- From: Muddflapp Mohican <nomail2482@xxxxxxx>
- Date: Sun, 20 Apr 2008 17:59:44 -0500
If the database contains filenames that were not parsed with no_conceal,
then the online filename and the database filename need to be parsed with
no_conceal to see if they match and if they do, don't generate an exception.
Or maybe a table could be created using "Show Logical */table=*" that could
be used to verify that such-and-such device is the same as such-and-such-other
device.
I didn't know about an f$fid_to_name(), but I can see that it would probably
return the filename using the disk logical that the disk was mounted with.
To see what the disk was mounted with use f$getdvi(disk,"logvolnam").
Rich Jordan wrote:
On Apr 11, 10:01 pm, AEF <spamsink2...@xxxxxxxxx> wrote:.On Mar 24, 4:27 pm, Rich Jordan <jor...@xxxxxxxxxxx> wrote:
[...]
OBTW the comment about people unfamiliar with VMS syntax; I expectPlease, what are you trying to do? What is the purpose of this list?
they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to
follow it since we'd be telling them. I'd prefer not to give them
variances that might be confusing (extra "][" and missing ".") so it
makes sense to use the most basic and consistent syntax in the stored
information.
Thanks!
Rich
What are the users looking for when they use this list? What are they
going to do with the file-spec when they find the one they want? Are
they expected to retrieve the file from disk or tape? If so, why do
they need the list? And how are they going to do anything with it if
they don't have even a clue as to VMS file-specs? Etc.
My apologies if I'm missing something obvious, but I have no clue as
to what the point of all this is.
If the OP is not following this thread anymore, I' asking anyone else
who is to explain to me what the whole point of this is.
As usual, without the original motivation it is difficult to come up
with reasonably "optimized" (for lack of a better word I can't think
of offhand) solution.
Thanks!
AEF
Auditing changes to or moves of designated files for compliance to
certain government regulations.
A physical change of location (hidden by logicals) is still an
auditable event requiring documentation. Hence the need to know the
physical path at the time the audit database is generated, in order to
compare it to the "current" state when an audit report is run. A hash
of each file is retained, along with file create/modify timestamps and
FID; the FID is only meaningful on a given logical drive unit so the
drive name needs to be retained also, unmasked from any logicals.
The auditors are (as expected) well trained in suboptimal operating
systems like windows, but are not VMS-aware. Providing basic VMS file
specification information is not a problem but avoiding potentially
confusing variants such as paths with the embedded ][ is just a good
thing to do. Normalizing the stored pathnames also makes later
comparison and parsing more efficient and less likely to generate a
'false positive' path change event.
The auditors may never see the actual database. They will see a
report generated comparing the current 'state' of the system against
the archived state recorded in the database. The pathnames in that
report will come from one or the other (or both) locations when an
exception is noted.
- References:
- Prev by Date: Re: OT: IBM looking at Macintosh
- Next by Date: Re: Intel Itanium RAS Comparison with X86
- Previous by thread: Re: Divining the full pathname of a file, all logicals translated
- Next by thread: Re: Divining the full pathname of a file, all logicals translated
- Index(es):
Relevant Pages
|
Loading
