In a word, no. The removal of Delete access is hard coded into the
CREATE/DIRECTORY code. The protection placed on a newly created
directory follows normal RMS inheritance and default rules, except that
the D bits are cleared from the final SOGW mask. This intentional and
documented behaviour - see RTL Library LIB$ Reference manual for
routine LIB$CREATE_DIR, "protection-enable" parameter. This dates from
VMS V1.0 prior to the introduction of the "DIRECTORY bit" in V2 which is
now used by the XQP to force a check that a directory is empty before
deletion. In VMS V1.0 this was the only protection against accidently
deleting a directory file and "orphaning" any files contained within
it. Although there is now a more reliable mechanism to prevent
accidental deletion, the original behaviour is retained for
compatibility reasons.
If your intention is to ensure that the owner of a directory has
delete access, you can place an ACE in the ACL of the parent directory
explicitly granting Delete access. All directories created within will
inherit the ACE (which will also propagate downwards). For example:
$ SET DEFAULT SYS$LOGIN
$ SET SECURITY/ACL=(IDENTIFIER=GILLINGS,ACCESS=READ+WRITE+EXECUTE+DELETE) -
[-]GILLINGS.DIR
$ SET SECURITY/DEFAULT [...]*.DIR ! propagate to existing directories
$ CREATE/DIRECTORY [.X]
$ DIRECTORY/SECURITY X.DIR
Directory DISK$USER1:[GILLINGS]
X.DIR;1 [USERS,GILLINGS] (RWE,RWE,RE,E)
(IDENTIFIER=[USERS,GILLINGS],ACCESS=READ+WRITE+EXECUTE+DELETE)
This must be done for each user's directory tree, since the identifier
must be the same as the owner.
