Knob to turn off _POSIX_NO_TRUNC

Mark Blackman mark at exonetric.com
Tue Apr 5 14:35:52 UTC 2011


On 5 Apr 2011, at 15:16, Kostik Belousov wrote:

> From very old and gloomy SysV times I remembered filesystem behaviour
> that silently truncated the file name components to the NAME_MAX limit,
> that was, AFAIR, 14. To much of my dismay, I met some usermode software
> recently that blindly tried to create the file from externally provided
> name, and sometimes failed with ENAMETOOLONG in similar situation.
> The authors are not cooperative.
> 
> I ended up with the following hack, which almost turns off the
> _POSIX_NO_TRUNC behaviour, globally on the system. Patch allowed me
> to proceed. The cost in the default case is a single check, which is
> performed only on ENAMETOOLONG path.

If this is global, it might deal with a failing test when building Perl
on a ZFS-only system which also tests  this property.

In particular, I believe ZFS neither truncates nor returns an error for any 
pathname length, so I'm not sure what the right test result should be.

Building perl produces something like..

Only one test fails:
ok 25 - calling pathconf("/tmp", _PC_NO_TRUNC)
not ok 26 -     checking that the returned value is defined (it isn't)
or that errno is clear (it isn't, it's Invalid argument)
#   Failed test '       checking that the returned value is defined
#   (it isn't) or that errno is clear (it isn't, it's Invalid argument)'
#   at t/sysconf.t line 63.

This thread..

http://lists.freebsd.org/pipermail/freebsd-fs/2010-November/010069.html

talked about the NO_TRUNC behaviour in the context of ZFS.

- Mark


More information about the freebsd-fs mailing list