From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 15:44:57 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAC5B14F for ; Mon, 19 Jan 2015 15:44:56 +0000 (UTC) Received: from eu1sys200aog107.obsmtp.com (eu1sys200aog107.obsmtp.com [207.126.144.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37A7BE53 for ; Mon, 19 Jan 2015 15:44:55 +0000 (UTC) Received: from mail-wg0-f41.google.com ([74.125.82.41]) (using TLSv1) by eu1sys200aob107.postini.com ([207.126.147.11]) with SMTP ID DSNKVL0mWxRfbeWzDUaFv3BDJDE0cOXm56r4@postini.com; Mon, 19 Jan 2015 15:44:56 UTC Received: by mail-wg0-f41.google.com with SMTP id a1so10406527wgh.0 for ; Mon, 19 Jan 2015 07:44:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=uLxEH5gZKkQiG0ubkpNIPNitqdX30K3K77ARhESEA1k=; b=aIEJz0d1daeXPysLf4GHu9inPUyREm/3UNV6opQKJFLl0WoOB4yvKDSJq+nm3LXFnR 6gRrq3NHy2Si5Tp4fUUtvcDAFFGsr4Ly+QTsh1tlDTLGDqL4rc376llA8UykdQwGarNg r/R++tn0XtIStWmk2RiizpigYPgGlQktkmYJIhmNuB3Apj1g80XQTgYm5h+AP5lsb4BB Ulj+Uy81y+9fIKr11OLNNt66qVBlrMlIVU5/RRNJtxDAslsnvEiKh7KYCrBkxLTMZCwS 4cdfQkrTBdNMpCcIPQTA8RB1B46hDNGaOM+O7G801ppHpcAqyVyj5mLLwPorIsvPStxp /0Ww== X-Gm-Message-State: ALoCoQkg/TL/2FPh4vOxW2ifIPAi8WgsJeQa/6KmEVPHnvLu+pKMSQ1kK5D/v/1i7vR4duuM7Sos/X+qhjf+Qqb4G1R8ID8bp/MBg1TcF7vnePpVhnFs8xPerRKFsQ/t3yEKuUNvdpkWyshtIdk+iRupMSAduU8rLQ== X-Received: by 10.194.93.194 with SMTP id cw2mr61372677wjb.21.1421682267739; Mon, 19 Jan 2015 07:44:27 -0800 (PST) X-Received: by 10.194.93.194 with SMTP id cw2mr61372659wjb.21.1421682267598; Mon, 19 Jan 2015 07:44:27 -0800 (PST) Received: from mech-as221.men.bris.ac.uk (mech-as221.men.bris.ac.uk. [137.222.187.221]) by mx.google.com with ESMTPSA id gl11sm17714192wjc.40.2015.01.19.07.44.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 07:44:26 -0800 (PST) Date: Mon, 19 Jan 2015 07:44:26 -0800 (PST) X-Google-Original-Date: Mon, 19 Jan 2015 15:44:25 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id t0JFiP9r027957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Jan 2015 15:44:25 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id t0JFiP7O027952; Mon, 19 Jan 2015 15:44:25 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> To: mexas@bris.ac.uk, rmacklem@uoguelph.ca Subject: Re: old bug: mount_nfs path/name is limited to 88 chars Reply-To: mexas@bris.ac.uk In-Reply-To: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 15:44:57 -0000 >From rmacklem@uoguelph.ca Mon Jan 19 15:37:25 2015 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 >> >> is a show stopper for me. The path/name length is >> beyond my control, so I cannot make it shorter. >> >> This discussion seems inconclusive: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038543.html >> >> Is there no easy solution to this PR? >> Or is there no interest in fixing the issue? >> >Well, the "easy" solution is to just increase the value >of NNAMELEN and rebuild everything from sources to use >the modified sys/mount.h. (If you can run a modified >system built entirely from sources, I think you can do >this.) I can do this on several 10.1-stable systems, but I understood from the email trail that there is no guarantee that nothing will be broken by such change. I know there is never a guarantee, but.. >However, this can't be done in -current because it breaks >the statfs(2) syscall API, etc. Even on 10.1-stable I see in statfs(2): #define MNAMELEN 88 /* size of on/from name bufs */ So perhaps changing MNAMELEN will break statfs(2) on -stable too? Anton