git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Brandon Williams <bmwill@google.com>
To: Jeff King <peff@peff.net>
Cc: "Torsten Bögershausen" <tboegi@web.de>,
	git@vger.kernel.org, sbeller@google.com, jacob.keller@gmail.com,
	gitster@pobox.com, ramsay@ramsayjones.plus.com, j6t@kdbg.org,
	pclouds@gmail.com, larsxschneider@gmail.com
Subject: Re: [PATCH v4 0/5] road to reentrant real_path
Date: Wed, 4 Jan 2017 10:13:18 -0800	[thread overview]
Message-ID: <20170104181318.GC69227@google.com> (raw)
In-Reply-To: <20170104070107.huse2a6thz737epv@sigill.intra.peff.net>

On 01/04, Jeff King wrote:
> On Wed, Jan 04, 2017 at 07:56:02AM +0100, Torsten Bögershausen wrote:
> 
> > On 04.01.17 01:48, Jeff King wrote:
> > > On Tue, Jan 03, 2017 at 11:09:18AM -0800, Brandon Williams wrote:
> > > 
> > >> Only change with v4 is in [1/5] renaming the #define MAXSYMLINKS back to
> > >> MAXDEPTH due to a naming conflict brought up by Lars Schneider.
> > > 
> > > Hmm. Isn't MAXSYMLINKS basically what you want here, though? It what's
> > > what all other similar functions will be using.
> > > 
> > > The only problem was that we were redefining the macro. So maybe:
> > > 
> > >   #ifndef MAXSYMLINKS
> > >   #define MAXSYMLINKS 5
> > >   #endif
> > > 
> > > would be a good solution?
> > Why 5  ? (looking at the  20..30 below)
> > And why 5 on one system and e.g. on my Mac OS
> > #define MAXSYMLINKS     32  
> 
> I mentioned "5" because that is the current value of MAXDEPTH. I do
> think it would be reasonable to bump it to something higher.
> 
> > Would the same value value for all Git installations on all platforms make sense?
> > #define GITMAXSYMLINKS 20
> 
> I think it's probably more important to match the rest of the OS, so
> that open("foo") and realpath("foo") behave similarly on the same
> system. Though I think even that isn't always possible, as the limit is
> dynamic on some systems.
> 
> I think the idea of the 20-30 range is that it's small enough to catch
> an infinite loop quickly, and large enough that nobody will ever hit it
> in practice. :)

I agree that we should have similar guarantees as the OS provides,
especially if the OS already has MAXSYMLINKS defined.  What then, should
the fall back value be if the OS doesn't have this defined?  5 like we
have done historically, or something around the 20-30 range as Torsten
suggests?

-- 
Brandon Williams

  reply	other threads:[~2017-01-04 18:13 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-05 18:58 [PATCH] making real_path thread-safe Brandon Williams
2016-12-05 18:58 ` [PATCH] real_path: make " Brandon Williams
2016-12-05 19:57   ` Stefan Beller
2016-12-05 20:12     ` Brandon Williams
2016-12-05 20:38       ` Stefan Beller
2016-12-05 20:14   ` Stefan Beller
2016-12-05 20:16     ` Brandon Williams
2016-12-08  9:41       ` Duy Nguyen
2016-12-08 17:50         ` Brandon Williams
2016-12-06 23:44   ` Junio C Hamano
2016-12-07  0:10     ` Brandon Williams
2016-12-07  1:12       ` Ramsay Jones
2016-12-07 20:14         ` Torsten Bögershausen
2016-12-07 20:32           ` Junio C Hamano
2016-12-07 22:13             ` Brandon Williams
2016-12-08  7:55               ` Torsten Bögershausen
2016-12-08 18:41                 ` Johannes Sixt
2016-12-08 19:02                   ` Brandon Williams
2016-12-07 20:43       ` Johannes Sixt
2016-12-07 22:29         ` Brandon Williams
2016-12-08 11:32           ` Johannes Sixt
2016-12-08 16:54             ` Junio C Hamano
2016-12-08 23:58 ` [PATCH v2 0/4] road to reentrant real_path Brandon Williams
2016-12-08 23:58   ` [PATCH v2 1/4] real_path: resolve symlinks by hand Brandon Williams
2016-12-09  1:49     ` Jacob Keller
2016-12-09 14:33     ` Johannes Sixt
2016-12-09 20:04       ` Brandon Williams
2016-12-08 23:58   ` [PATCH v2 2/4] real_path: convert real_path_internal to strbuf_realpath Brandon Williams
2016-12-08 23:58   ` [PATCH v2 3/4] real_path: create real_pathdup Brandon Williams
2016-12-09 14:35     ` Johannes Sixt
2016-12-08 23:58   ` [PATCH v2 4/4] real_path: have callers use real_pathdup and strbuf_realpath Brandon Williams
2016-12-09 12:33   ` [PATCH v2 0/4] road to reentrant real_path Duy Nguyen
2016-12-09 19:42     ` Brandon Williams
2016-12-10 11:02       ` Duy Nguyen
2016-12-12 18:16   ` [PATCH v3 " Brandon Williams
2016-12-12 18:16     ` [PATCH v3 1/4] real_path: resolve symlinks by hand Brandon Williams
2016-12-12 22:19       ` Junio C Hamano
2016-12-12 22:50         ` Brandon Williams
2016-12-12 23:32           ` Junio C Hamano
2016-12-12 18:16     ` [PATCH v3 2/4] real_path: convert real_path_internal to strbuf_realpath Brandon Williams
2016-12-12 22:20       ` Junio C Hamano
2016-12-12 18:16     ` [PATCH v3 3/4] real_path: create real_pathdup Brandon Williams
2016-12-12 22:25       ` Junio C Hamano
2016-12-12 18:16     ` [PATCH v3 4/4] real_path: have callers use real_pathdup and strbuf_realpath Brandon Williams
2016-12-12 22:26       ` Junio C Hamano
2016-12-12 23:47         ` Junio C Hamano
2016-12-12 23:58           ` Stefan Beller
2016-12-13  1:15             ` Brandon Williams
2016-12-13  6:39               ` Junio C Hamano
2016-12-21 21:51     ` [PATCH bw/realpath-wo-chdir] real_path: canonicalize directory separators in root parts Johannes Sixt
2016-12-21 22:33       ` Brandon Williams
2016-12-22  6:07         ` Johannes Sixt
2016-12-22 17:33           ` Brandon Williams
2016-12-22 18:54             ` Johannes Sixt
2016-12-22 19:33             ` Junio C Hamano
2017-01-03 19:09     ` [PATCH v4 0/5] road to reentrant real_path Brandon Williams
2017-01-03 19:09       ` [PATCH v4 1/5] real_path: resolve symlinks by hand Brandon Williams
2017-01-03 19:09       ` [PATCH v4 2/5] real_path: convert real_path_internal to strbuf_realpath Brandon Williams
2017-01-03 19:09       ` [PATCH v4 3/5] real_path: create real_pathdup Brandon Williams
2017-01-03 19:09       ` [PATCH v4 4/5] real_path: have callers use real_pathdup and strbuf_realpath Brandon Williams
2017-01-04  1:07         ` Jacob Keller
2017-01-04 18:14           ` Brandon Williams
2017-01-03 19:09       ` [PATCH v4 5/5] real_path: canonicalize directory separators in root parts Brandon Williams
2017-01-04  0:48       ` [PATCH v4 0/5] road to reentrant real_path Jeff King
2017-01-04  6:56         ` Torsten Bögershausen
2017-01-04  7:01           ` Jeff King
2017-01-04 18:13             ` Brandon Williams [this message]
2017-01-04 18:22               ` Stefan Beller
2017-01-04 21:46                 ` Jacob Keller
2017-01-04 21:55                   ` Brandon Williams
2017-01-04 22:01       ` [PATCH v5 " Brandon Williams
2017-01-04 22:01         ` [PATCH v5 1/5] real_path: resolve symlinks by hand Brandon Williams
2017-01-04 22:01         ` [PATCH v5 2/5] real_path: convert real_path_internal to strbuf_realpath Brandon Williams
2017-01-04 22:01         ` [PATCH v5 3/5] real_path: create real_pathdup Brandon Williams
2017-01-04 22:01         ` [PATCH v5 4/5] real_path: have callers use real_pathdup and strbuf_realpath Brandon Williams
2017-01-04 22:01         ` [PATCH v5 5/5] real_path: canonicalize directory separators in root parts Brandon Williams
2017-01-08  3:09         ` [PATCH v5 0/5] road to reentrant real_path Junio C Hamano
2017-01-09 18:04           ` Brandon Williams
2017-01-09 18:18             ` Junio C Hamano
2017-01-09 18:24               ` Brandon Williams
2017-01-09 19:26                 ` Junio C Hamano
2017-01-09 18:50               ` [PATCH 1/2] real_path: prevent redefinition of MAXSYMLINKS Brandon Williams
2017-01-09 18:50                 ` [PATCH 2/2] real_path: set errno when max number of symlinks is exceeded Brandon Williams

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=20170104181318.GC69227@google.com \
    --to=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=jacob.keller@gmail.com \
    --cc=larsxschneider@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=ramsay@ramsayjones.plus.com \
    --cc=sbeller@google.com \
    --cc=tboegi@web.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).