From owner-FreeBSD-tech-jp@jp.freebsd.org  Mon Jan 31 22:32:42 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id WAA36872;
	Mon, 31 Jan 2000 22:32:42 +0900 (JST)
	(envelope-from owner-FreeBSD-tech-jp@jp.FreeBSD.org)
Received: from serio.al.rim.or.jp (serio.al.rim.or.jp [202.247.191.123])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id WAA36867
	for <freebsd-tech-jp@jp.freebsd.org>; Mon, 31 Jan 2000 22:32:41 +0900 (JST)
	(envelope-from kuriyama@sky.rim.or.jp)
Received: from mail1.rim.or.jp by serio.al.rim.or.jp (8.8.8/3.7W/HMX-12) with ESMTP id WAA22502 for <freebsd-tech-jp@jp.freebsd.org>; Mon, 31 Jan 2000 22:32:41 +0900 (JST)
Received: from rhea.sky.rim.or.jp (ppp515.kt.rim.or.jp [202.247.140.165]) by mail1.rim.or.jp (3.7W/)
	id WAA17771 for <freebsd-tech-jp@jp.freebsd.org>; Mon, 31 Jan 2000 22:32:40 +0900 (JST)
Received: from localhost.sky.rim.or.jp (localhost [127.0.0.1])
	by rhea.sky.rim.or.jp (8.9.3/3.7W/rhea-1.2) with ESMTP id WAA72647
	for <freebsd-tech-jp@jp.freebsd.org>; Mon, 31 Jan 2000 22:32:39 +0900 (JST)
Date: Mon, 31 Jan 2000 22:32:38 +0900
Message-ID: <864sbunz7t.wl@localhost.sky.rim.or.jp>
From: Jun Kuriyama <kuriyama@sky.rim.or.jp>
To: Tech List <freebsd-tech-jp@jp.freebsd.org>
User-Agent: Wanderlust/2.2.16 (No Son Of Mine) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 8) (Bryce Canyon) (i386--freebsd)
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: multipart/mixed;
 boundary="Multipart_Mon_Jan_31_22:32:38_2000-1"
Reply-To: FreeBSD-tech-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+990727
X-Sequence: FreeBSD-tech-jp 2686
Subject: [FreeBSD-tech-jp 2686] Forward: Re: "rm -rf" behavior on readonly nfs
Errors-To: owner-FreeBSD-tech-jp@jp.freebsd.org
Sender: owner-FreeBSD-tech-jp@jp.freebsd.org
X-Originator: kuriyama@sky.rim.or.jp

--Multipart_Mon_Jan_31_22:32:38_2000-1
Content-Type: text/plain; charset=ISO-2022-JP


$B!!(BBruce $B$,1>$C$F$k$N$G!"(Bunlink() $B$r8+$F$_$?$s$G$9$,!"(B
src/sys/kern/vfs_syscalls.c $B$N(B VOP_LEASE() $B$H$+(B VOP_REMOVE() $B$H$+$C$F2?(B
$B<T$G$7$g$&!)(B

$B!!(Bsrc/sys $B$N2<$r(B grep $B$7$F$_$?8B$jDj5A$7$F$$$k>l=j$,8+Ev$?$i$J$$$C$]$$$s(B
$B$G$9$,!D!D!#(B

$B!!(BEROFS $B$rJV$9A0$K%U%!%$%k$,B8:_$9$k$+$I$&$+$r%A%'%C%/$9$l$PLdBj2r7h!"$C(B
$B$F$3$H$N$h$&$KFI$a$k$s$G$9$,!#(B



--Multipart_Mon_Jan_31_22:32:38_2000-1
Content-Type: message/rfc822

From bde@zeta.org.au  Mon Jan 31 00:49:38 2000
Return-Path: <bde@zeta.org.au>
Received: (from uucp@localhost)
	by rhea.sky.rim.or.jp (8.9.3/3.7W/rhea-1.2) with UUCP id AAA58421
	for kuriyama@sky.rim.or.jp; Mon, 31 Jan 2000 00:49:38 +0900 (JST)
Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by rayearth.rim.or.jp (8.8.8/3.5Wpl2-uucp1/RIMNET) with SMTP
	id SAA25702 for <kuriyama@sky.rim.or.jp>; Sun, 30 Jan 2000 18:33:00 +0900 (JST)
Received: (qmail 1819 invoked from network); 30 Jan 2000 09:32:55 -0000
Received: from bde.zeta.org.au (203.2.228.102)
  by gidora.zeta.org.au with SMTP; 30 Jan 2000 09:32:55 -0000
Date: Sun, 30 Jan 2000 20:32:51 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@alphplex.bde.org
To: Jun Kuriyama <kuriyama@sky.rim.or.jp>
cc: current@FreeBSD.ORG
Subject: Re: "rm -rf" behavior on readonly nfs
In-Reply-To: <86aeloo22e.wl@localhost.sky.rim.or.jp>
Message-ID: <Pine.BSF.4.21.0001302012500.10432-100000@alphplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 30 Jan 2000, Jun Kuriyama wrote:

> I found difference between "rm -rf" for non-exist file on readonly nfs
> and usual non-writable directory.
> 
> In this example, /usr/src is readonly nfs mounted and /usr/bin is
> normal filesystem but not writable.  And file "a" is not exist.
> 
> -----
> % rm /usr/bin/a
> rm: /usr/bin/a: No such file or directory
> % rm -f /usr/bin/a
> % rm -rf /usr/bin/a
> % rm /usr/src/a
> rm: /usr/src/a: No such file or directory
> % rm -f /usr/src/a
> % rm -rf /usr/src/a
> rm: /usr/src/a: Read-only file system
> %
> -----
> 
> For "-f" option, last behavior is expected one, or not?

The kernel returns EROFS for unlink() without even looking up the last
component of the filename.  This is a cosmetic bug IMO.  The errors
listed in POSIX.1 are not required to be checked for in the given
order.  However, checking in that order usually gives the most logical
results.  For unlink() and similar syscalls, EROFS is at the end of
the list.

Once unlink() returns EROFS, POSIX.2 requires the error to be reported
for rm -f (POSIX.2 requires rm -f to be silent about ENOENT but not about
all other errors).

Bruce

~~~~ // kuriyama@sky.rim.or.jp
        // kuriyama@FreeBSD.org

--Multipart_Mon_Jan_31_22:32:38_2000-1--
