Can I modify a file's ACL without updating it's revised date/time?

[Mark Noll]

We have a directory tree with thousands of files that need to have their ACLs modified. It's a simple change, but it will update the Revised date/time on all the files. That date is relevant to us since it shows when the contents of a file were last modified. I've dug around for a way to modify the ACLs without touching the Revised date but have come up empty. Any suggestions on a way to accomplish this?

I've always found it annoying that a file's Revised date gets modified whenever the security settings for the file are changed. I understand the need, but I wish there were separate fields for tracking when the contents of a file were changed and when the meta-data surrounding a file was changed. I see there's now a Modified date when using dir/full (ODS-5 feature?), but ours are all null so I'm not sure when/where/how it gets used.

[Steven Schweda]

I don't know of a DCL-level method. There is
a FIB$M_NORECORD/fib$v_norecord thing which
can be used in a program. (Example code
available in UnZip [.vms]vms.c.)

[Craig A Berry]

Well, here's a cheat that might even be good enough, depending on your requirements. Unwrap the following one-liner:

$ perl -e "my $mt=(stat($ARGV[0]))[8]; `SET ACL $ARGV[0]`; utime $mt,$mt,$ARGV[0];" file.dat

This operates on the file "file.dat", first pulling the modification time out of the return of stat, then spawning a process to run the SET ACL command (which as you've noted, tags the RDT), and finally calling utime to set the modification time back to what we originally retrieved. A side effect of using stat is that since it returns times in seconds, you'll lose the ticks and only reset the time to the nearest second, which may or may not be good enough for you.

My example has no error checking. You could add some, but this three-step hack is never going to be an atomic operation. The stat, the SET ACL, and the utime are three independent operations and if you've got other people adding, removing, or modifying files while you're working on them, there are race conditions here big enough to drive a truck through.

But if you've got or can schedule exclusive access and the nearest second is good enough, this might be all you need.

[Hein van den Heuvel · Accepted solution]

Yeah, it would have been nice, considerate, if SET FILE had the option NOT to change the modification date. I recently witnessed an MMS rebuild 'blow' up thinking everything had change after a silly DOD requirement was fullfilled.

You did not mention the OpenVMS version, but did mention ODS5 and modified date, so i'm guessing you are up to date and could potentially use
$ rdt = F$FILE(file,"RDT")
$ SET SECU ... 'file'
$ SET FILE/ATTR=REVDATE="rdt'

Except that... some double-negative logic around FIB$V_NORECORD is done backwards (best I can tell in SETFILE. It sets the NORECORD bit UNLESS REVDATE is asked for. SO a SET FILE/ATTR=CREDATE will not change the modified date, but requesting REVDATE will leave norecord cleared and thus the Revision data will end up reflecting the time of the command. :-(.
(Guy... did you not dabble in that area when you were a young lad? :-).

So short of patching SETFILE you may want to use your own tool. For example some code like below.

Hope this helps,
Hein


#include descrip
#include string
#include stdio
#include RMS
main(int argc, char *argv[])
{
struct FAB fab = cc$rms_fab;
struct XABRDT dat = cc$rms_xabrdt;
int stat, sys$open(), sys$bintim(), sys$close();
int date_dx[2];

if (argc < 3) {
printf ("Usage: %s \"\"\n", argv[0]);
return 1;
}
date_dx[0] = strlen (argv[2]);
date_dx[1] = (int) argv[2];
fab.fab$l_fna = argv[1];
fab.fab$b_fns = strlen(fab.fab$l_fna);
fab.fab$b_fac = FAB$M_PUT;
fab.fab$l_xab = &dat;

stat = sys$open ( &fab );
if (stat & 1) stat = sys$bintim ( date_dx, &dat.xab$q_rdt);
if (stat & 1) stat = sys$close ( &fab );
return stat;
}

[Wim Van den Wyngaert]

If you have an old VMS version you cam replace set file/at by touch/new_date=xxx of the freeware cd.

Wim

[Mark Noll]

Got it to work!

Thanks to all for the replies, but especially to Hein for pointing me to the SET FILE/ATT command.

We're on OpenVMS 8.3 but I was looking at 8.2 docs so I didn't realize there were date options in SET FILE/ATT. I've now got 8.3 docs online so decided to play with the various options.

Here's how the various date attributes work:
- CREDATE, BAKDATE, and EXPDATE work as expected and modify that date.
- REVDATE (as Hein noted) doesn't work because it sets the revised date to the date/time the command is entered rather than the specified value. It also bumps the revised date counter.
- MODDATE and ACCDATE don't do anything -- perhaps this is a future enhancement or something that needs to be turned on?
- ATTDATE modifies the revised date -- this is what I wanted! -- and doesn't bump the revised date counter. However, it only works if I first try to set the REVDATE. I think it's related to bumping the revised date counter (shown in parens to right of Revised date), but I'm not sure.

Following Hein's example, I can now do this:
$ rdt = F$FILE(file,"RDT")
$ SET SECURITY... file
$ SET FILE/ATTR=REVDATE="''rdt'" file
$ SET FILE/ATTR=ATTDATE="''rdt'" file

I found that I can't set the Revised date to earlier than the Create date (makes sense) but I can set it in the future.

I haven't found an explanation for these new dates but it would seem the Attributes date would be for tracking when the file attributes where last modified so the Revised date wouldn't be touched.

I don't know whether to call this a feature or a bug, but I'm taking advantage of it either way. :)

[H.Becker]

>>> - MODDATE and ACCDATE don't do anything

on an ODS5 disk without volume characteristics set to ACCESS_DATES at volume initialization time or with a SET VOLUME.

[Jur van der Burg]

DFU can set the revision date and count to anything you would like.

$ mc dfu set file.dat//REVISION_DATE=xxx/RVCOUNT=...

Jur.