From owner-freebsd-fs@FreeBSD.ORG Tue Apr 5 14:35:52 2011 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 0E11F1065672 for ; Tue, 5 Apr 2011 14:35:52 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay0.exonetric.net (relay0.exonetric.net [82.138.248.161]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8B88FC16 for ; Tue, 5 Apr 2011 14:35:51 +0000 (UTC) Received: from [192.168.111.107] (unknown [62.244.179.66]) by relay0.exonetric.net (Postfix) with ESMTP id 8A66557232; Tue, 5 Apr 2011 15:35:50 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) From: Mark Blackman In-Reply-To: <20110405141631.GA78089@deviant.kiev.zoral.com.ua> Date: Tue, 5 Apr 2011 15:35:49 +0100 Message-Id: <7696AAE3-E04B-492F-9D96-3B526CFDFEE6@exonetric.com> References: <20110405141631.GA78089@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Knob to turn off _POSIX_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: Tue, 05 Apr 2011 14:35:52 -0000 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