o Althought this is not specified in POSIX.1e, the UFS ACL implementation   coerces the deletion of a default ACL on a directory when no default   ACL EA is present to success.  Because the UFS EA implementation doesn't   disinguish the EA failure modes "that EA name has not been   administratively enabled" from "that EA name has no defined data",   there's a potential conflict in error return values.  Normally, the   lack of administratively configured EA support is coerced to   EOPNOTSUPP to indicate that ACLs are not available; in this case,   it is possible to get a successful return, even if ACLs are not   available because EA support for them has not been enabled.
o Althought this is not specified in POSIX.1e, the UFS ACL implementation
  coerces the deletion of a default ACL on a directory when no default
  ACL EA is present to success.  Because the UFS EA implementation doesn't
  disinguish the EA failure modes "that EA name has not been
  administratively enabled" from "that EA name has no defined data",
  there's a potential conflict in error return values.  Normally, the
  lack of administratively configured EA support is coerced to
  EOPNOTSUPP to indicate that ACLs are not available; in this case,
  it is possible to get a successful return, even if ACLs are not
  available because EA support for them has not been enabled.

  Expand the comment in ufs_setacl() to identify this case.

Obtained from:	TrustedBSD Project

jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase