In some email I received from Ernst J. du Toit, they wrote:
[...]
> 	2) A MUCH bigger problem is that standard archive tools (tar, etc)
> 	   obviously does NOT work with ACLs and you lose all that extra 
> 	   information.
> 
> 	   AIX solves this (refer /bin/mksysb script on AIX) by going a 
> 	   find with perms of -200000000 to pick out the files with ACLs
> 	   and then stores the ACLs in a file. These ACLs are then applied 
> 	   during the restore part of the script - very messy....

Or if ACL's were normal files with a special "attachment" to a regular
file, at least you don't lose the ACL when you tar/dump/cpio.

Back to CDF's for a sec, find on HP-UX has a flag (-H (?)) as does ls
(-H) to show the CDF's.  How does a CDF work ? (for those that don't
know).  The CDF is actually a directory with a special flag set. Under
that directory, you create files for each "context".  If the directory
is "empty" or has no matching "context" then the directory doesn't show
up in a normal "ls".  If there is a file matching the current "context"
in the directory, that file becomes the directory.  So if I have a
directory "foo" and make it a CDF, then create a file "foo/default" and
do "ls -alg foo", I see the stats for "foo/default".  To reference "foo"
as the directory, "foo+" would be used.  CDF's with no matching context
are sometimes called "hidden directories" (hence the +/- H).  This can
sometimes cause distress if you use them as such (and I have :-() because
you can easily lose files when doing backups which ignore them.

Now, ACL's, HP-UX on ACL permissions checking:

    Access Check Algorithm
      ACL entries can be categorized by four levels of specificity.  In
      access checking, ACLs are compared to the effective user and group IDs
      in this order:

           (u.g, rwx)     specific user, specific group
           (u.%, rwx)     specific user, no specific group
           (%.g, rwx)     no specific user, specific group
           (%.%, rwx)     no specific user, no specific group

      Once an entry for the combination of a process effective user ID and
      effective group ID (or any supplementary group ID) is matched, no
      further (that is, less specific) entries are checked.  More specific
      entries that match take precedence over any less specific ones that
      also match.

      If a process has more than one group ID (that is, a non-null
      supplementary groups list), more than one (u.g, mode) or (%.g, mode)
      entry might apply for that process.  If so, the access modes in all
      matching entries (of the same level of specificity, u.g or %.g) are
      OR'd together.  Access is granted if the resulting mode bits allow it.
      Since entries are unique, the order of entries in each entry type is
      insignificant.

      Because the traditional UNIX permission bits are mapped into base ACL
      entries, they are included in access checks.

      If a request is made for more than one type of access, such as opening
      a file for both reading and writing, access is granted only if the
      process is allowed all requested types of access.  Note that access
      can be granted if the process has two groups in its groups list, one
      of which is only allowed read access, and the other of which is only
      allowed write access.  In other words, even if the requested access is
      not granted by any one entry, it may be granted by a combination of
      entries due to the process belonging to several groups.
...
I can't find any support, however, for ACL's in tar, etc (although they do
support CDF's if told to).

Darren