From owner-freebsd-fs@FreeBSD.ORG Thu Nov 11 13:22:59 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FCA7106566B for ; Thu, 11 Nov 2010 13:22:59 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id A228A8FC0C for ; Thu, 11 Nov 2010 13:22:58 +0000 (UTC) Received: from c122-107-121-73.carlnfd1.nsw.optusnet.com.au (c122-107-121-73.carlnfd1.nsw.optusnet.com.au [122.107.121.73]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oABDMoZN016053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Nov 2010 00:22:51 +1100 Date: Fri, 12 Nov 2010 00:22:50 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Martin Simmons In-Reply-To: <201011111206.oABC6VYG027663@higson.cam.lispworks.com> Message-ID: <20101112000011.A1372@besplex.bde.org> References: <871369D9-7D63-4CE0-BB87-B8C46A62B271@exonetric.com> <201011111206.oABC6VYG027663@higson.cam.lispworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and pathconf(_PC_NO_TRUNC) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 13:22:59 -0000 On Thu, 11 Nov 2010, Martin Simmons wrote: >>>>>> On Wed, 10 Nov 2010 22:28:27 +0000, Mark Blackman said: >> >> I note that when testing the pathconf(2) NO_TRUNC property >> on a ZFS filesystem, I get a ENOENT, "No such file or directory". >> >> I'm not sure if this qualifies as correct behaviour, but thought >> a learned soul on this list could enlighten me. >> >> I've attached the C snippet I used for testing. >> >> #include >> #include >> #include >> #include >> #include >> >> int main(int argc, char *argv[]){ >> int result; >> >> result=pathconf(argv[1], _PC_NO_TRUNC); >> printf("for %s: no_trunc is %d\n",argv[1],result); >> if (result<0) >> perror(NULL); >> 1; >> } > > Your call to printf is clobbering the real errno, which is EINVAL. That is an > allowed value according to the pathconf man page: > > [EINVAL] The implementation does not support an association of > the variable name with the associated file. > > So it is correct, but maybe not useful. I think POSIX requires (in cross-references that are hard to read in ASCII versions) _PC_NO_TRUNC to be supported for directories (only). POSIX clearly says that whether _PC_NO_TRUNC is supported for non-directories is implementation-defined. For some feature test variables, it may be necessary to test both the pathconf variable and the compile-time variable (_POSIX_NO_TRUNC here). Under FreeBSD, _POSIX_NO_TRUNC is 1, which means that this feature applies to all files, but this is just wrong since individual file systems can and do return 0 for _PC_NO_TRUNC (msdosfs is one example -- it has too allow truncation since file names are often too long for 8.3 format, and truncating them is what msdos would do). So applications shouldn't trust _POSIX_NOTRUNC. Fortunately, it is easiest to never use it (except in programs that test for bugs like the FreeBSD one). It is not useful, since even if it is correct then in most cases it will be 0 (meaning that whether the feature applies is fs-dependent, so that _PC_NO_TRUNC must be used). It is easiest to always just use _PC_NO_TRUNC and not use the ifdef tangle involving _POSIX_NO_TRUNC that is needed to sometimnes avoid using _PC_NO_TRUNC> msdosfs may also be wrong in returning 0 for _PC_NO_TRUNC in both the 8.3 and longnames cases. I don't know what msdos does in the longnames case, but with long names there is no need to truncate. Bruce