From owner-cvs-all Fri Oct 26 22:39:20 2001 Delivered-To: cvs-all@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B168037B405; Fri, 26 Oct 2001 22:39:17 -0700 (PDT) Received: (from rwatson@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f9R5dHY50655; Fri, 26 Oct 2001 22:39:17 -0700 (PDT) (envelope-from rwatson) Message-Id: <200110270539.f9R5dHY50655@freefall.freebsd.org> From: Robert Watson Date: Fri, 26 Oct 2001 22:39:17 -0700 (PDT) To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/ufs/ufs ufs_acl.c X-FreeBSD-CVS-Branch: HEAD Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG rwatson 2001/10/26 22:39:17 PDT Modified files: sys/ufs/ufs ufs_acl.c Log: 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 Revision Changes Path 1.8 +7 -2 src/sys/ufs/ufs/ufs_acl.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message