site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=J2r41OKWpGLuOLD/7hkXx8tk5bTL6T8Ot9jDUhppM6VASQAsQVg8AUWf0cCUp/eytGwnEItwu1X7mzQLB9DLdtl9TKdbtsOVN2IpcJBmZ83SVrKeKaj7S3pLHJ4kbBYeu48xMWLc2KVZYaXrrWDe7kvHyUD6W8NR2u+68r8ZELk= ; Chris, Thanks for the tip -- I sometimes forget that I actually do have access to the source:-) And as another benefit to being able to examine the library source, I discovered that several of the non-posix extensions present in the Darwin ACL api are no-oped/broken as well (e.g. acl_set_link_np, acl_get_link_np) ... saving me several hours of probing around in the dark. - Brendan On Wed, 16 Aug 2006 07:04:26 +0100, Chris Ridd wrote:
If you look at the 10.4.6 sources via:
<http://darwinsource.opendarwin.org/10.4.6.ppc/Libc-391.2.5/posix1e/acl_file .c>
you'll see that they are indeed mostly stubs. Your debugger was right :-(
Cheers,
Chris On 16/8/06 4:43, Brendan Creane <bcreane@yahoo.com> wrote:
Hello Darwin-List,
I've been trying to remove the access control list entries associated with a file, and not having success. All of the following consistently return ENOENT: acl_delete_file_np(), acl_delete_link_np(), and acl_delete_fd_np(), though the path or file descriptor is valid. When I walk into the library routine's assembly code, it looks like the call is stubbed out -- pop the stack and then return to the caller.
Does anyone know the status of the acl_delete routines under OS X 10.4.7? If indeed they aren't functional, is the best work-around to delete acl entries one-by-one?
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com
participants (1)
-
Brendan Creane