From owner-freebsd-current@FreeBSD.ORG Thu May 20 12:58:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32D7116A4CE for ; Thu, 20 May 2004 12:58:22 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC23643D1D for ; Thu, 20 May 2004 12:58:21 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i4KJwA90053901; Thu, 20 May 2004 12:58:11 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <40AD0DD0.90900@freebsd.org> Date: Thu, 20 May 2004 12:58:08 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Reyenga References: <000501c43d74$19dc5fb0$0200000a@redline> In-Reply-To: <000501c43d74$19dc5fb0$0200000a@redline> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: setfacl and mtime X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2004 19:58:22 -0000 Craig Reyenga wrote: > > I've been toying with ACLs lately, and I noticed that ACL operations change > the mtime of the file, whereas chmod does not. Is this functionality > intentional? More importantly, can it be turned off? In particular, this is yet another way that the following two commands seem to differ, even though (by my understanding), they should be exactly interchangable: chmod u=rw file setfacl -m user::rw- file The second changes the mtime, the first does not. The second does not work on all filesystems, the first does. The ACL routines I wrote for bsdtar (long story why this was necessary...) are careful to convert changes to basic ACL entries (such as the second example above) to the equivalent chmod. It seems to me that the library/kernel acl routines should also behave this way? Tim