Date: Fri, 12 Nov 2010 00:22:50 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Martin Simmons <martin@lispworks.com> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and pathconf(_PC_NO_TRUNC) Message-ID: <20101112000011.A1372@besplex.bde.org> In-Reply-To: <201011111206.oABC6VYG027663@higson.cam.lispworks.com> References: <871369D9-7D63-4CE0-BB87-B8C46A62B271@exonetric.com> <201011111206.oABC6VYG027663@higson.cam.lispworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <unistd.h>
>> #include <stdlib.h>
>> #include <stdio.h>
>> #include <string.h>
>> #include <errno.h>
>>
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101112000011.A1372>