Re: rm -rf behavior on readonly nfs
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
: :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
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
: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
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