From owner-freebsd-current@freebsd.org Tue Sep 12 21:24:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10345E1EDBA; Tue, 12 Sep 2017 21:24:03 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id 2EECA634E9; Tue, 12 Sep 2017 21:24:01 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Tue, 12 Sep 2017 23:23:11 +0200 Authentication-Results: connect.ultra-secure.de; iprev=pass; auth=pass (plain); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 217.71.83.52 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=217.71.83.52; helo=[192.168.1.200]; envelope-from= Received: from [192.168.1.200] (217-071-083-052.ip-tech.ch [217.71.83.52]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id F2D42BBD-4578-47E4-B239-97A38462D027.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES256-SHA verify=NO); Tue, 12 Sep 2017 23:23:08 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: extending the maximum filename length (pointer to patch)[request for input] From: Rainer Duffner In-Reply-To: <041393BA-94E3-4D22-95C8-EF0634746DC3@gmail.com> Date: Tue, 12 Sep 2017 23:23:56 +0200 Cc: cem@freebsd.org, "freebsd-fs@freebsd.org" , freebsd-current Message-Id: References: <0154558d-b2ad-af97-3960-3e392678f709@freebsd.org> <8d04540b-6daf-aa13-5648-0ec2541cbae6@freebsd.org> <041393BA-94E3-4D22-95C8-EF0634746DC3@gmail.com> To: Ben RUBSON X-Mailer: Apple Mail (2.3124) X-Haraka-GeoIP: EU, CH, 451km X-Haraka-ASN: 24951 X-Haraka-GeoIP-Received: X-Haraka-ASN: 24951 217.71.80.0/20 X-Haraka-ASN-CYMRU: asn=24951 net=217.71.80.0/20 country=CH assignor=ripencc date=2003-08-07 X-Haraka-FCrDNS: 217-071-083-052.ip-tech.ch X-Haraka-p0f: os="Mac OS X " link_type="DSL" distance=15 total_conn=5 shared_ip=N X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=ham autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 3919, bad: 1, connections: 4345, history: 3918, asn_score: 452, asn_connections: 464, asn_good: 452, asn_bad: 0, pass:asn, asn_all_good, relaying Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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: Tue, 12 Sep 2017 21:24:03 -0000 > Am 12.09.2017 um 23:11 schrieb Ben RUBSON : >=20 > On 12/9/17 2:17 pm, Conrad Meyer wrote: >> On Sat, Sep 9, 2017 at 9:09 AM, Julian Elischer = wrote: >>> maybe we could get it into -current. >>> It'd be silly to have to have people re-inventing hte wheel all the = time. >>> How about you put those changes into the reviews.freebsd.org and we = can get >>> some general consensus on them. >>> We'll have to do similar for the Asian customers and anyone who uses = UTF-8. >>> So it >>> would be silly to have to develop it all again (but subtly different = of >>> course). >>>=20 >>> The key issue is how many system calls and other APIs would be = broken, >>> and how many would be broken in a non backwards compatible way? >>>=20 >>> We would need it in a stable/10 and 11 branch but if the patch is = isolated >>> enough we could carry it forward until we get to 12. >>>=20 >>> One has to allow people to do whatever they are used to with = Windows. >>> And in this case the issue is serving files over samba to windows = machines. >> Hey Julian, >>=20 >> I've thrown the patch up at https://reviews.freebsd.org/D12330 . I >> haven't actually tested it on FreeBSD, but it does compile. We also >> have some patches against contrib/pjdfstest to fix those tests = against >> long file names, but I think we can hold off on those changes until >> we've nailed down what the architectural change will be (if any). >=20 > Hi Conrad, >=20 > This patch makes me think about another related bug #184340 : > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D184340 = > It is about PATH_MAX which in some cases can be too small. >=20 > Not sure if it's the case / and how to do it, > but perhaps it is time to raise some other limits / > think about a global solution regarding these length limits ? >=20 > Many thanks ! >=20 > Ben And there=E2=80=99s also this bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215067 = "g_dev_taste: make_dev_p() failed on importing pool with snapshots with = long names=E2=80=9C But maybe that has nothing to do with it.