From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.0 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 2A0971F406 for ; Wed, 10 Jan 2018 00:13:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753187AbeAJANI convert rfc822-to-8bit (ORCPT ); Tue, 9 Jan 2018 19:13:08 -0500 Received: from elephants.elehost.com ([216.66.27.132]:47981 "EHLO elephants.elehost.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753359AbeAJANH (ORCPT ); Tue, 9 Jan 2018 19:13:07 -0500 X-Virus-Scanned: amavisd-new at elehost.com Received: from pangea (CPE00fc8d49d843-CM00fc8d49d840.cpe.net.cable.rogers.com [99.229.179.249]) (authenticated bits=0) by elephants.elehost.com (8.15.2/8.15.2) with ESMTPSA id w0A0CwVq065699 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Jan 2018 19:12:58 -0500 (EST) (envelope-from rsbecker@nexbridge.com) From: "Randall S. Becker" To: "'Johannes Sixt'" Cc: , "Bill Honaker" , "'Joachim Schmitz'" References: <47197839-720f-3c8d-729c-3fcb615aeb36@kdbg.org> In-Reply-To: <47197839-720f-3c8d-729c-3fcb615aeb36@kdbg.org> Subject: RE: [PATCH] Prototype PATH_MAX length detection in tests, demonstrated in t0001-init.sh Date: Tue, 9 Jan 2018 19:12:52 -0500 Message-ID: <005d01d389a7$c55da9f0$5018fdd0$@nexbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Mailer: Microsoft Outlook 16.0 Content-Language: en-ca Thread-Index: AQIsbxSdIT0HX8bTkZvBsKb6qpXvfgHeGaYPoqt5u/A= Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On January 9, 2018 6:01 PM, Johannes Sixt wrote: > Am 09.01.2018 um 19:12 schrieb Randall S. Becker: > > This patch create a configuration variable PATH_MAX that corresponds > > with the value in limits.h. The value of PATH_MAX, if supplied, is > > added to BASIC_CFLAGS and will validate with limits.h. PATH_MAX is > > also added to GIT-BUILD-OPTIONS and is available in the git test > > suite. > > > > This patch also creates a test_expected_success_cond, taking a single > > function as first argument. In the t0001-init.sh case, subtest 34 this > > function is test_path_max_is_sane, although any > > 0/1 returning function can be used. The prototype allows the long base > > path test to be skipped if PATH_MAX is less than 2048 bytes. > > OK, but... This was suggested in a previous thread, so I prototyped. I'm ok with not going ahead with it but still, it might help some platforms. Still, see down. > > diff --git a/t/t0001-init.sh b/t/t0001-init.sh index c4814d2..58dad87 > > 100755 > > --- a/t/t0001-init.sh > > +++ b/t/t0001-init.sh > > @@ -315,7 +315,7 @@ test_expect_success 'init with separate gitdir' ' > > test_path_is_dir realgitdir/refs > > ' > > > > -test_expect_success 'init in long base path' ' > > +test_expect_success_cond 'test_path_max_is_sane' 'init in long base path' > ' > > # exceed initial buffer size of strbuf_getcwd() > > component=123456789abcdef && > > test_when_finished "chmod 0700 $component; rm -rf $component" > && > > ... why would you want to skip this test? If I'm reading the test case correctly, > it requires only a path length of 127 plus whatever your build directory is plus > a score for the trash directory. That should pose a problem only if your > system is even more crippled than Windows with its PATH_MAX of 260. I'm encountering strange warnings, while looking into the details of what test t0001 fails in spots. These include: #24 warning: templates not found x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 which exceeds 2K, but that's just content, right, and not causing an apparent breakage. # 34. Admittedly it was shorter than 2K, but there is something weird in this path that I can't find, causing a failure out of fts_read from gnulib. Initialized empty Git repository in /home/ituglib/randall/git/t/trash directory.t0001-init/123456789abcdef/123456789abcdef/123456789abcdef/123456789abcdef/123456789abcdef/123456789abcdef/123456789abcdef/123456789abcdef/newdir/.git/ rm: fts_read failed: No such file or directory This error is coming from some of shell utilities (in this case rm) used in the test rather than git code itself. While well within the supported path length of the operating system/platform (1K), there is an acknowledged issue that is causing breakage when paths get large enough (even only this large, unfortunately). We're at 221 breaks out of 12982-ish, which is good, but have to otherwise visually check each breakage until the fts_read problem is resolved - I know what the issue is, but I don't have the auth to resolve it, so waiting on HPE platform development for that. Of course, manually patching that many breaks is equally unwieldy, so I'm willing to tolerate not having this patch applied at this time. > This can probably be reduced to > > test_path_max_is_sane () { > test "${PATH_MAX:-4000}" -ge 2048 > } Thanks. I'll change that no matter what. Cheers, Randall