From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 18-MAY-1992 20:38:36.37
To:	leichter@LRW.COM, info-vax@sri.com
CC:	GWDGI::"info-vax@sri.com"@CRVAX.SRI.COM, MOELLER@CRVAX.SRI.COM
Subj:	Application ACEs (was re: Use RMS to hold file type)

JERRY LEICHTER <leichter@LRW.COM> wrote about the problem of attaching
some extra information to VMS files:
>[...]
> The closest thing to what you want is an application-specific ACE.  These are
> described in the Introduction to Systems Services, and basically just provide
> a way to store a bunch of arbitrary data - a word of flag bits and up to 255
> bytes per ACE - in the file header.  RENAME wouldn't touch it, but the killer
> is COPY, which probably won't copy it.  (There's no way to create an applica-
> tion-specific ACE without writing a bunch of code, so I can't test this; but
> COPY certainly won't propagate identifier ACE's.)
>[...]

Some comments:
	- creating an application ACE is not hard (if you can live with
	  numeric data):
		$ SET FILE/ACL=(app,flags=nnn,size={8+4*{#longwords}},-
			data={longword1},{longword2}...)
	  Apparently one can specify an ACE the same way as DIRECTORY/ACL
	  displays it - I wonder if that's documented anywhere.

	- COPY indeed does not propagate ACL's (to differently named copies),
	  but you can always use BACKUP (which does).

	- on the other hand, COPY (and virtually all programs except BACKUP)
	  propagate an old file's ACE's when they create a new version.

	- COPY/OVERLAY does not destroy file ACLs.