Date: Fri, 2 Jun 2000 11:34:37 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Chris Costello <chris@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/miscfs/fdesc fdesc.h fdesc_vnops.c Message-ID: <200006021534.LAA41585@khavrinen.lcs.mit.edu> In-Reply-To: <200006020702.AAA11016@freefall.freebsd.org> References: <200006020702.AAA11016@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Fri, 2 Jun 2000 00:02:46 -0700 (PDT), Chris Costello <chris@FreeBSD.org> said: > - Do not allow VOP_SETATTR to modify underlying vnodes at all. This caused > problems when fetch(1) was passed `-o -'. The rationale of this change > is that applications attempting to change underlying vnodes for /dev/fd > nodes are improperly written and the use of this interface should not > ever have been encouraged. Proper alternatives are fchmod, fchown and > others. Huh? The only operations `fetch' *ever* performs on /dev/stdout are: fopen fseek fwrite fread (iff the server provides an MD5) (which will fail anyway) I'd make the additional argument that this change is bogus because: If fetch had been passed `-o /dev/fd/69', it would be unreasonable to expect fetch to examine the argument it was given, notice that it began with the magic string `/dev/fd/' and parse out the file-descriptor number. This is not to say that there are no bugs in `fetch' -- I found a couple in the vicinity of rm() just by inspection, one of which actually bit me once. (Hint: never interrupt fetch while running as root with `-o /dev/null' -- it will delete the device node.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006021534.LAA41585>