git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Johannes Sixt'" <j6t@kdbg.org>
Cc: <git@vger.kernel.org>, "Bill Honaker" <bhonaker@xid.com>,
	"'Joachim Schmitz'" <jojo@schmitz-digital.de>
Subject: RE: [PATCH] Prototype PATH_MAX length detection in tests, demonstrated in t0001-init.sh
Date: Tue, 9 Jan 2018 19:12:52 -0500	[thread overview]
Message-ID: <005d01d389a7$c55da9f0$5018fdd0$@nexbridge.com> (raw)
In-Reply-To: <47197839-720f-3c8d-729c-3fcb615aeb36@kdbg.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


  reply	other threads:[~2018-01-10  0:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 18:12 [PATCH] Prototype PATH_MAX length detection in tests, demonstrated in t0001-init.sh Randall S. Becker
2018-01-09 18:20 ` Randall S. Becker
2018-01-09 23:00 ` Johannes Sixt
2018-01-10  0:12   ` Randall S. Becker [this message]
2018-01-10 18:16     ` Johannes Sixt
2018-01-10 18:27       ` Randall S. Becker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='005d01d389a7$c55da9f0$5018fdd0$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=bhonaker@xid.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=jojo@schmitz-digital.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).