From owner-freebsd-stable@FreeBSD.ORG Thu Jan 22 22:50:31 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 126C09DF; Thu, 22 Jan 2015 22:50:31 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id E0E39A0; Thu, 22 Jan 2015 22:50:30 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 22 Jan 2015 14:53:31 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id t0MMoLFf017112; Thu, 22 Jan 2015 14:50:21 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id t0MMoKkH017111; Thu, 22 Jan 2015 14:50:20 -0800 (PST) (envelope-from ambrisko) Date: Thu, 22 Jan 2015 14:50:20 -0800 From: Doug Ambrisko To: Willem Jan Withagen Subject: Re: old bug: mount_nfs path/name is limited to 88 chars Message-ID: <20150122225020.GA13161@ambrisko.com> References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> <54BDA9DD.5040608@delphij.net> <54BE3FDC.9030904@digiware.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BE3FDC.9030904@digiware.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd current , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 22:50:31 -0000 On Tue, Jan 20, 2015 at 12:45:32PM +0100, Willem Jan Withagen wrote: | On 2015-01-20 2:05, Xin Li wrote: | >>Doing it in 11 makes sense since there is a compat layer for 10 | >>now? if I knew all of the steps I would happily do them as annoys | >>me from time to time as well with the path length issue. | > | >Compat layer may break applications in other funny ways and we | >probably have to return e.g. ENAMETOOLONG for legacy applications if | >the names are too long to fit into the buffer, but I don't see any | >easy solution either: I wish we have bumped it in 2003 when the struct | >receives its first big revamp by bumping all statistic fields to 64-bit. | | On 2015-01-20 1:23, Allan Jude wrote:> On 2015-01-19 16:20, Garrett > | > Especially with ZFS, I find I have a lot more mounts now, under longer | > and longer path names, and then I have | > .zfs/snapshots/snapshotnamehere/path/to/file | > | > etc. | > | > Definitely a +1 for "this is something we need for 11" | | +1 | | Well to be honest: Things are already broken for me ATM. | I do have paths that are too long, and tools trip over it. | | Things like building the locate database just don't have everything. | Which is a pain, especially for finding things fast in backups of ZFS, | where the path is even more convoluted that what Allan suggests | | So whether being bitten by the cat of the dog: it still hurts. | | Perhaps it is an intermediate solution to add new settings which are | going to be used for userspace programs, like USER_MNAMELEN and | USER_PATH_MAX. It will certainly give ENAMETOOLONG back when it involves | systemcalls. But then a lot of the other tool stuff would just function. I have a patch at: http://www.ambrisko.com/doug/mount/latest.patch for -current (Nov). It should work with most file systems, that is I tried to cover them all. I haven't tested with ZFS but it should work. I left some debug "HELLO's" in there just to make sure mounting looked right. They can be safely deleted. If someone wants to test it and report issues (with a simple test case) I can fix it and add it to my test script. This code won't be going into FreeBSD now since the 64 bit inode will negate the need for it since the size will be a lot larger. Thanks, Doug A.