Date: Wed, 6 Apr 2011 05:41:37 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: Knob to turn off _POSIX_NO_TRUNC Message-ID: <20110406053603.F3067@besplex.bde.org> In-Reply-To: <20110405185751.GE78089@deviant.kiev.zoral.com.ua> References: <20110405141631.GA78089@deviant.kiev.zoral.com.ua> <20110405154002.GD78089@deviant.kiev.zoral.com.ua> <20110405183104.2304d94e@ernst.jennejohn.org> <201104051316.32704.jhb@freebsd.org> <20110405185751.GE78089@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Apr 2011, Kostik Belousov wrote:
> On Tue, Apr 05, 2011 at 01:16:32PM -0400, John Baldwin wrote:
>> Personally, I find this a bit hackish. You could always "fix" the 3rd
>> party software by using LD_PRELOAD() to implement a wrapper around
>> open() that trimmed the name if open() fails with ENAMETOOLONG.
Or install it on one of the file systems that has {_PC_NO_TRUNC} = 0
(might need a chroot, and the following fix).
> Ok, I am taking the patch aside then. Please note that the change
> as is allowed any vfs syscall taking the path, to proceed. Also,
> the arbitrary path element, not only the last one, was handled.
> But this is only a question of amount of code in the preloaded
> library.
There is one thing that can be changed without incrementing the bug
count: make {_PC_NO_TRUNC} = 0 actually work. Currently, this fails
for pathnames larger than NAME_MAX, since vfs doesn't know what
either {NAME_MAX} or {_PC_NO_TRUNC} are and always assumes the global
values.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110406053603.F3067>