From owner-freebsd-arch Mon Sep 17 9:17:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id BDCAC37B40C; Mon, 17 Sep 2001 09:17:06 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8HGGwa19460; Mon, 17 Sep 2001 19:16:58 +0300 (EEST) (envelope-from ru) Date: Mon, 17 Sep 2001 19:16:57 +0300 From: Ruslan Ermilov To: arch@FreeBSD.org, freebsd-standards@bostonradio.org Cc: Bruce Evans , Garrett Wollman Subject: Re: Fixing chown(8) and friends to handle symlinks properly Message-ID: <20010917191657.A19072@sunbay.com> References: <20010913202742.C2458@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010913202742.C2458@sunbay.com>; from ru@FreeBSD.org on Thu, Sep 13, 2001 at 08:27:42PM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! Unless I hear from somebody that they are wishing to review this patch, I will take it as if noone currently has enough spare time to review this, and will just commit this patch on Thursday, 20th. :-) Thanks, On Thu, Sep 13, 2001 at 08:27:42PM +0300, Ruslan Ermilov wrote: > [Bcc'ed to -current in a hope for a more wider auditory] > > The attached patch fixes the handling of symlinks in chown(8) > and chgrp(1). It is currently broken in many different ways. > Basically, it is broken because -h is not supported with -RH > or -RL. The actual problem lies in the depths of the fts(3) > implementation, in particular, how the `fts_stat' is getting > initialized. The trick in supporting roughly any combination > of command line flags ([-h] [-R [-H | -L | -P]]) was to avoid > looking into the `fts_stat' (as we don't know whether it is > from lstat(2) or stat(2)), and just call chown(2) or lchown(2) > as appropriate. Although it may seem as a big performance > degradation, in fact it isn't, as kernel doesn't modify the > inode if nothing is to be changed. > > This work is based on the latest POSIX drafts, and the > superior NetBSD implementation (which I had to fix in a > number of cases anyway, in particular, handling of dead > symlinks in the -h case). > > The new algorithm of handling a symlink encountered during > a file tree traversal works as follows: > > +-------------+-------------------------------------------------+ > | Options | Action | > +-------------+-------------------------------------------------+ > | -- | chown | > | -h | lchown | > | | Notes: only FTS_SL symlinks may end up here | > +-------------+-------------------------------------------------+ > | -RP | SKIP | > | -RP -h | lchown | > | | Notes: only FTS_SL symlinks may end here | > +-------------+-------------------------------------------------+ > | -RH | SKIP | > | -RH -h | lchown | > | | Notes: both FTS_SL and FTS_SLNONE symlinks | > | | may end up here. FTS_SLNONE's are deadlinks | > | | specified as command line arguments | > +-------------+-------------------------------------------------+ > | -RL | SKIP | > | -RL -h | lchown | > | | Notes: only FTS_SLNONE symlinks may end up here | > +-------------+-------------------------------------------------+ > > Or, in a more compact form: > > : if symlink { > : if -R > : -h ? lchmod : SKIP > : else > : -h ? lchmod : chmod > : } else > : chmod > > For the testing purposes, I'd suggest creating the following > structure, which should be self-explaining: > > afile > alink -> afile > deadlink -> nofile > dir > adir -> dir > dir/afile > dir/alink -> afile > dir/deadlink -> nofile > > PLEASE TEST THIS PATCH THROUGHLY! > > NOTE: This implementation is still not quite POSIX compliant, as > the latter says to follow a symlink (in the -R case) only if it > points to an object of type directory. Our fts(3) routines are > unable of doing this. > > If this patch is accepted, I'm going to revisit and fix the rest > of the fts(3) utilities that are listed on the symlink(7) manpage. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message