Re: rm -rf behavior on readonly nfs

2000-02-15 Thread Jun Kuriyama

From: Bruce Evans [EMAIL PROTECTED]
 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.

I tried to fix this problem.  I think it is very dirty code but it
works to return ENOENT for "rm -rf" with read-only nfs mounted
filesystem.  Could someone clean up this?


Index: nfs_vnops.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.150
diff -u -r1.150 nfs_vnops.c
--- nfs_vnops.c 2000/01/05 00:32:18 1.150
+++ nfs_vnops.c 2000/02/15 15:49:39
@@ -820,9 +820,6 @@
struct proc *p = cnp-cn_proc;
 
*vpp = NULLVP;
-   if ((flags  ISLASTCN)  (dvp-v_mount-mnt_flag  MNT_RDONLY) 
-   (cnp-cn_nameiop == DELETE || cnp-cn_nameiop == RENAME))
-   return (EROFS);
if (dvp-v_type != VDIR)
return (ENOTDIR);
lockparent = flags  LOCKPARENT;
@@ -833,6 +830,11 @@
struct vattr vattr;
int vpid;
 
+   if ((flags  ISLASTCN) 
+   (dvp-v_mount-mnt_flag  MNT_RDONLY) 
+   (cnp-cn_nameiop == DELETE || cnp-cn_nameiop == RENAME))
+   return (EROFS);
+
if ((error = VOP_ACCESS(dvp, VEXEC, cnp-cn_cred, p)) != 0) {
*vpp = NULLVP;
return (error);
@@ -894,6 +896,10 @@
goto nfsmout;
}
nfsm_getfh(fhp, fhsize, v3);
+
+   if ((flags  ISLASTCN)  (dvp-v_mount-mnt_flag  MNT_RDONLY) 
+   (cnp-cn_nameiop == DELETE || cnp-cn_nameiop == RENAME))
+   return (EROFS);
 
/*
 * Handle RENAME case...


Jun Kuriyama // [EMAIL PROTECTED]
// [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: rm -rf behavior on readonly nfs

2000-02-15 Thread Matthew Dillon

:
:From: Bruce Evans [EMAIL PROTECTED]
: 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.
:
:I tried to fix this problem.  I think it is very dirty code but it
:works to return ENOENT for "rm -rf" with read-only nfs mounted
:filesystem.  Could someone clean up this?

The general idea seems sound enough.  I'd rather wait until after
the release before putting this (or a similar patch) in, though,
since the bug isn't really all that serious.

I recommend submitting a PR for it and then emailing me the PR
number.  I will assign it to myself so I don't forget and will
then patch it in after the release.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]
:
:
:Index: nfs_vnops.c
:===
:RCS file: /home/ncvs/src/sys/nfs/nfs_vnops.c,v
:retrieving revision 1.150
:diff -u -r1.150 nfs_vnops.c
:--- nfs_vnops.c2000/01/05 00:32:18 1.150
:+++ nfs_vnops.c2000/02/15 15:49:39
:@@ -820,9 +820,6 @@
:   struct proc *p = cnp-cn_proc;
: 
:   *vpp = NULLVP;
:-  if ((flags  ISLASTCN)  (dvp-v_mount-mnt_flag  MNT_RDONLY) 
:-  (cnp-cn_nameiop == DELETE || cnp-cn_nameiop == RENAME))
:-  return (EROFS);
:   if (dvp-v_type != VDIR)
:   return (ENOTDIR);
:   lockparent = flags  LOCKPARENT;
:@@ -833,6 +830,11 @@
:   struct vattr vattr;
:   int vpid;
: 
:+  if ((flags  ISLASTCN) 
:+  (dvp-v_mount-mnt_flag  MNT_RDONLY) 
:+  (cnp-cn_nameiop == DELETE || cnp-cn_nameiop == RENAME))
:+  return (EROFS);
:+
:   if ((error = VOP_ACCESS(dvp, VEXEC, cnp-cn_cred, p)) != 0) {
:   *vpp = NULLVP;
:   return (error);
:@@ -894,6 +896,10 @@
:   goto nfsmout;
:   }
:   nfsm_getfh(fhp, fhsize, v3);
:+
:+  if ((flags  ISLASTCN)  (dvp-v_mount-mnt_flag  MNT_RDONLY) 
:+  (cnp-cn_nameiop == DELETE || cnp-cn_nameiop == RENAME))
:+  return (EROFS);
: 
:   /*
:* Handle RENAME case...
:
:Jun Kuriyama // [EMAIL PROTECTED]
:// [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: rm -rf behavior on readonly nfs

2000-01-30 Thread Giorgos Keramidas

On Sun, Jan 30, 2000 at 09:06:33AM +0900, 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?

This happens on either NFS-mounted or real directories.  It think that since
the manual of rm(1) says:

 -f   Attempt to remove the files without prompting for confirma-
  tion, regardless of the file's permissions.  If the file does
  not exist, do not display a diagnostic message or modify the
  exit status to reflect an error.

it ought to print nothing in such a case.  Let me know if the small patch
shown below helps in correcting this.  I can't check this cause I got bitten
by getflags() in(s)anity last night when I cvsup'ed.

The diff -u output is:

%%% patch begins here %%%
--- /usr/src/bin/rm/rm.cSat Jan 29 01:14:23 2000
+++ rm.cSun Jan 30 09:32:18 2000
@@ -196,7 +196,9 @@
}
continue;
case FTS_ERR:
-   errx(1, "%s: %s", p-fts_path, strerror(p-fts_errno));
+   if (!fflag)
+   errx(1, "%s: %s", p-fts_path,
+strerror(p-fts_errno));
case FTS_NS:
/*
 * FTS_NS: assume that if can't stat the file, it
%%% patch ends here %%%

-- 
Giorgos Keramidas,  keramida @ ceid . upatras . gr 
"Don't let your schooling interfere with your education." [Mark Twain]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: rm -rf behavior on readonly nfs

2000-01-30 Thread Matthew Dillon

:This happens on either NFS-mounted or real directories.  It think that since
:the manual of rm(1) says:
:
: -f   Attempt to remove the files without prompting for confirma-
:  tion, regardless of the file's permissions.  If the file does
:  not exist, do not display a diagnostic message or modify the
:  exit status to reflect an error.
:
:it ought to print nothing in such a case.  Let me know if the small patch
:shown below helps in correcting this.  I can't check this cause I got bitten
:by getflags() in(s)anity last night when I cvsup'ed.

No, it should definitely print an error.  If the file didn't exist 
it should stay silent but if the file exists and cannot be removed,
that should generate an error.

The -f option does not mean "silently fail", it simply means that no
error message should be printed if the error is innocuous.  i.e. you
try to remove a file that is already removed.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

:The diff -u output is:
:
:%%% patch begins here %%%
:--- /usr/src/bin/rm/rm.cSat Jan 29 01:14:23 2000
:+++ rm.cSun Jan 30 09:32:18 2000
:@@ -196,7 +196,9 @@
:}
:continue;
:case FTS_ERR:
:-   errx(1, "%s: %s", p-fts_path, strerror(p-fts_errno));
:+   if (!fflag)
:+   errx(1, "%s: %s", p-fts_path,
:+strerror(p-fts_errno));
:case FTS_NS:
:/*
: * FTS_NS: assume that if can't stat the file, it
:%%% patch ends here %%%
:
:-- 
:Giorgos Keramidas,  keramida @ ceid . upatras . gr 
:"Don't let your schooling interfere with your education." [Mark Twain]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: rm -rf behavior on readonly nfs

2000-01-30 Thread Bruce Evans

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



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message