Revised date time changes vms file attribute

[Matthew Booth]

I have noticed that some files get there revised date/time changed but not all. For example I have a login.com that was created 15-SEP-2005 and has not been changed. However, today a $dir/full login.com shows that it has been revised. Revised: 27-NOV-2007 01:56:29.60 (293)
My only suspect is Data Protector? maybe?
Any hints/tips?

Thanks,
Matt

[Jon Pinkley]

Matt,

My guess is that you are renaming the file. Do you have a command procedure to purge to n versions and reset the version numbers? A rename will change the revision and the modification data.

It appears something other than an editor is opening your login.com file for write. Even if no changes are made, the revision date will be changed when the file is closed. (I wish there was an option so this wouldn't happen unless there was actually a write operation done).

Do you have a "touch" utility on your system? Or perhaps a third party tool that searches files, but doesn't open them for read only access?

Note the date stamp. What runs then? You could use image accounting or put an audit ACE on the file and use auditing to determine what is doing it.

Note the revision count (293). This has been "modified" 293 times since 15-SEP-2005, That could be because of renaming, opening for write, or because something like DFU is explicitly changing the timestamps and revision count.

Jon

[Robert Gezelter]

Matthew,

I would agree with Jon. Something is repeatedly touching the file.

In addition to doing the approach that Jon mentioned, you can do a series of DIR/FULL commands on a daily basis to see when the count is jumping, that will narrow the search a bit.

- Bob Gezelter, http://www.rlgsc.com

[Matthew Booth]

Thanks for the replies. I will try the acl approach and will get back to you.

-Matt

[John Gillings]

Matt,
Note that as of V8.3 there are more dates maintained in file header:

Created: 28-NOV-2007 07:58:43.14
Revised: 28-NOV-2007 07:58:43.42 (1)
Expires:
Backup:
Effective:
Recording:
Accessed:
Attributes:
Modified:

Are any of the other dates changing?

Depending on where and how you ask for "Modified" date, you may get different answers.

Opening a file with WRITE intent will update the revision date, even if you don't actually modify the file. For example:

$dir/full sys$login:login.com;
...
Created: 24-OCT-2007 14:16:44.59
Revised: 24-OCT-2007 14:16:44.60 (1)
...
$ open/read/write lgi sys$login:login.com
$ close lgi
$ dir/full sys$login:login.com;

Created: 24-OCT-2007 14:16:44.59
Revised: 28-NOV-2007 08:13:33.23 (2)

I don't believe there's anything in OpenVMS that will open LOGIN.COM for write access. I wouldn't expect Data Protector to change anything either (except perhaps the backup date).

The audit ACE is your best bet to find the culprit.

[DSM_1]

One of my annoyances with VMS is that, with regard to "Revised" date-time, it does not distinguish between a change to the file contents and some (but not all) changes to the file attributes. (I am using VMS 7.3-2).

An example of where this can be annoying, is when I find a file without World access, that I wish World to read. The command SET SEC/PROT=(W:RE) changes the "Revised" date, and I lose any information as to when the file was last REALLY changed. Thankfully, with file versioning, the creation date-time is usually good enough.

[Kris Clippeleyr]

Matt,

The problem with a DIR/FULL is that the date given after the word "Revised:" in not the actual revision date. It is the most recent of the "revision date", the "attributes changed date" and the "data modified date". At least on ODS-5 volumes.

Have a look at the difference regarding dates in the output of DIR/FULL and QDSB/FULL. You can download QDSB from our website ( http://www.quadratrix.be/qdsb.html )

Regards,
Kris (aka Qkcl)

[Hein van den Heuvel]

DSM,

One of the main annoyances with the Unix files systems is that there is no true create time&date. Thankfully due to the lack of versioning, the modification date often suffices.

:-)

>>The command SET SEC/PROT=(W:RE) changes the "Revised" date, and I lose any information as to when the file was last REALLY changed

But the file DID really change (assuming the protect was different). If the file where to be damaged and needed to be restored, then you would want that latest protection (owner, name,...) restored right? So that (protection) modification needs to trigger a modification time based backup mechanisme

The new additional dates address this problem.

Still, it would be nice if SET FILE had an /KEEP_REVISION (or some such).

Hein.

[DSM_1]

Hein,

I have yet to suffer the blight of a Unix system, although the day is not far off, unfortunately.

My point of reference was MVS (which I think is now called z/OS). The security information was not a file property, it was maintained separately from the resources and accounts it controlled. So giving someone (or everyone) permission to view a file did not change the file. My recollection is that the modification date could be relied upon, and in the most common case (a member of a PDS), the modified-by user account was also visible.

But I have become quite fond of VMS and I am sure I would find things to grizzle about in MVS or z/OS if I were ever to go back to it.

[Jan van den Ende]

John G wrote:

>>>
Opening a file with WRITE intent will update the revision date, even if you don't actually modify the file.
<<<

Strictly speaking, this is _NOT_ true!
As can be seen by opening a file for write, and then doing the DIR/FULL

The Revision Date gets updated, when a file that was opened for write is CLOSED.

The distinction well only rarely be relevant, but IMHO it has to be noted.

fwiw,

Proost.

Have one on me.

jpe