From owner-cvs-sys  Mon Apr  6 10:48:12 1998
Return-Path: <owner-cvs-sys>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id KAA24943
          for cvs-sys-outgoing; Mon, 6 Apr 1998 10:48:12 -0700 (PDT)
          (envelope-from owner-cvs-sys)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA24757;
          Mon, 6 Apr 1998 10:47:02 -0700 (PDT)
          (envelope-from peter@FreeBSD.org)
From: Peter Wemm <peter@FreeBSD.ORG>
Received: (from peter@localhost)
	by freefall.freebsd.org (8.8.8/8.8.5) id KAA02811;
	Mon, 6 Apr 1998 10:44:41 -0700 (PDT)
Date: Mon, 6 Apr 1998 10:44:41 -0700 (PDT)
Message-Id: <199804061744.KAA02811@freefall.freebsd.org>
To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG
Subject: cvs commit: src/sys/ufs/ufs ufs_readwrite.c
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

peter       1998/04/06 10:44:41 PDT

  Modified files:
    sys/ufs/ufs          ufs_readwrite.c 
  Log:
  Don't panic if a VOP_READ() gets through on a short link, Just Do It
  (because we can :-).  This means you can open a link file (or pseudo-file
  in the case of short links where the data is stored in the inode rather
  than disk blocks) and read the contents.
  However, trap any writes from the user as it's difficult to do the right
  thing in all cases.  A link may be short and the user may be trying to
  extend it beyond the limit and so on.  Although.. being able to re-target
  a symlink without deleting it first might have been nice.
  This stuff is a bit perverse since symlink() and readlink() calls can
  end up actually being implemented as read/write vnode ops.
  
  Reviewed by: phk
  
  Revision  Changes    Path
  1.48      +17 -7     src/sys/ufs/ufs/ufs_readwrite.c