From owner-freebsd-bugs  Tue May  9 18:18:22 1995
Return-Path: bugs-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id SAA02685
          for bugs-outgoing; Tue, 9 May 1995 18:18:22 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA02676
          for <freebsd-bugs@FreeBSD.org>; Tue, 9 May 1995 18:18:18 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA06009; Tue, 9 May 1995 18:17:59 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199505100117.SAA06009@gndrsh.aac.dev.com>
Subject: Re: strange symlinks
To: terry@cs.weber.edu (Terry Lambert)
Date: Tue, 9 May 1995 18:17:58 -0700 (PDT)
Cc: Bernard.Steiner@Germany.EU.net, freebsd-bugs@FreeBSD.org
In-Reply-To: <9505092214.AA19830@cs.weber.edu> from "Terry Lambert" at May 9, 95 04:14:48 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1640      
Sender: bugs-owner@FreeBSD.org
Precedence: bulk

> 
> > Assumption: directory /tmp exits, owned by bin.bin mode 1777
> > then ln -s /tmp/foo /tmp/bar produces symlink /tmp/bar *owned* by bin
> > regardless of who issued the symlink command, and subsequent rm /tmp/bar
> > is refused for non-owner, i.e. any normal user except for bin and root.
> > 
> > This is bogus.
> 
> It's a generic 4.4 problem with making symlinks in the directory entries
> themselves.  Probably when the sticky bit is set, it ought to make the
> old-style links instead.
> 
> > The next one may be a general 4.4 problem...
> > assumption: /tmp/foo does not exist, /tmp/bar is a symlink to /tmp/foo.
> > chdir("/tmp/bar") fails with ENOENT, but at the same time
> > mkdir("/tmp/bar", 0x777) fails with EEXIST.
> 
> I think this is a generic result of the path component item evaluation
> order.  I guess the only thing to say is that "according to the code,
> this is correct behaviour"  8-).
> 
> > Third, whatever happened to the fchdir() syscall that I vaguely remember
> > having had in (at least) 386BSD0.1 ?
> 
> It had *better* still be there!  I've been using it with a couple of
> minor code changes to get about a 15% performance increase out of
> Samba by keeping an open descriptor for the exported file system to
> make all opens relative instead of having to traverse every component
> up to the path on the volume itself.

It should be there, from my 2.0-current system:
gndrsh# locate fchdir
/usr/share/man/man2/fchdir.2

It is a system call.


-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                   Custom computers for FreeBSD