Date: Thu, 11 Nov 2010 14:32:25 +0000 From: Mark Blackman <mark@exonetric.com> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and pathconf(_PC_NO_TRUNC) Message-ID: <43792CD8-6127-4402-8A4F-5DFD894F7256@exonetric.com> In-Reply-To: <20101112005719.O1598@besplex.bde.org> References: <871369D9-7D63-4CE0-BB87-B8C46A62B271@exonetric.com> <201011111206.oABC6VYG027663@higson.cam.lispworks.com> <86371A88-1474-4A51-8C84-05C4A71A9135@exonetric.com> <20101112002522.V1372@besplex.bde.org> <20101112005719.O1598@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11 Nov 2010, at 14:17, Bruce Evans wrote: > where zfs seems to succeed for a lot > of features that shouldn't apply to fifos, and then falls back to > vop_stdpathconf() which succeeds for even more features where it = shouldn't. > fifo_pathconf() only succeeds for _PC_LINK_MAX, _PC_PIPE_BUF and > _PC_CHOWN_RESTRICTED. Its setting of _PC_LINK_MAX is wrong, since the > value of this is fs-dependent. _PC_PIPE_BUF is of course = pipe+fifo-dependent > so its setting belongs here and somewhere for pipes (I can't see where = it > is supported for fpathconf() on pipes). _PC_CHOWN_RESTRICTED also = shouldn't > be set here, but perhaps fifos can know a system-wide setting and = repeat it, > as other file systems do. >=20 > Correct layering would probably result in vop_stdpathconf() not = existing. > It is currently more or less correct only for devfs, and is only used = by > zfs, coda, devfs, fdescfs and portalfs. >=20 > Bruce Ok, I'll file that bug then. I wonder how Solaris handles pathconf, but = that's another question. Cheers, Mark=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43792CD8-6127-4402-8A4F-5DFD894F7256>