All of lore.kernel.org
 help / color / mirror / Atom feed
From: "erik elfström" <erik.elfstrom@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Git List <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v5 2/5] setup: sanity check file size in read_gitfile_gently
Date: Tue, 28 Apr 2015 21:28:12 +0200	[thread overview]
Message-ID: <CAMpP7NY76Tj_=_6Evxvox20OmQ5LnNiK1j4VHLd0jKhRmci51g@mail.gmail.com> (raw)
In-Reply-To: <20150428060222.GK24580@peff.net>

On Tue, Apr 28, 2015 at 8:02 AM, Jeff King <peff@peff.net> wrote:
>
> My understanding is that PATH_MAX is set absurdly low on Windows
> systems (and doesn't actually represent the real limit of a path!).
> Since the value is picked arbitrarily anyway, could use something more
> independent (like 100K or something, which is large enough to be beyond
> absurd and small enough that a malloc isn't a big deal)?
>
> -Peff

I'm happy to set the limit to anything that makes everybody feel safe. I'll set
it to 1MB to be on the safe side.

I'm not sure though how the code (in general) is supposed to keep working if
a path can exceed PATH_MAX? A cursory search for PATH_MAX comes
up with char array sizes and check-and-die kind of things. If a path is longer
then surely we will be unable to handle it and abort in all sorts of places?

Are you only worried we might have a submodule with a too long path (that will
create various other problems in different codepaths) that we may mistakenly
clean (if it doesn't trigger any other abort earlier in the clean call
chain) or do
you want clean to keep working and do the right thing even in this case?

While digging around looking at this I also noticed that there is
another problem
I have overlooked previously.

read_gitfile_gently will call is_git_directory at the very end and it
contains the
following check at the very beginning:

    if (PATH_MAX <= len + strlen("/objects"))
        die("Too long path: %.*s", 60, suspect);

Now, this is good in the way that we will avoid mistakenly cleaning
stuff because
the path is too long but also bad because it makes read_gitfile_gently
behave very
ungently in this case.

I suspect I should make a gentle version of this also. The question is
what to do
in clean if the path is reported as too long? Abort? Avoid cleaning it
to be safe?
Ignore and clean it?

is_git_directory is also called from the new is_git_repository
directly but here I think
dying is ok since this path is a path in the working tree and if we
can't handle the paths
in the tree then there seem to be little point in trying to go on (as
opposed to when
some string in a file is too large for a path)

Thoughts?

/Erik

  parent reply	other threads:[~2015-04-28 19:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-25  9:06 [PATCH v4 0/5] Improving performance of git clean Erik Elfström
2015-04-25  9:06 ` [PATCH v4 1/5] setup: add gentle version of read_gitfile Erik Elfström
2015-04-25 16:51   ` Junio C Hamano
2015-04-25 16:54     ` Junio C Hamano
2015-04-25  9:06 ` [PATCH v4 2/5] setup: sanity check file size in read_gitfile_gently Erik Elfström
2015-04-25 16:47   ` Junio C Hamano
2015-04-25 17:59     ` Erik Elfström
2015-04-26  4:29       ` Junio C Hamano
2015-04-26  6:49         ` [PATCH v5 0/5] Improving performance of git clean Erik Elfström
2015-04-26  6:49           ` [PATCH v5 1/5] setup: add gentle version of read_gitfile Erik Elfström
2015-04-28  6:17             ` Jeff King
2015-04-28 20:07               ` erik elfström
2015-04-28 20:19                 ` Jeff King
2015-04-28 20:34                   ` Jonathan Nieder
2015-04-28 20:36                     ` Jeff King
2015-04-28 20:42                       ` Jonathan Nieder
2015-04-28 20:48                         ` Jeff King
2015-04-28 21:06                           ` Jonathan Nieder
2015-04-28 23:34                           ` Junio C Hamano
2015-04-29 23:47             ` Stefan Beller
2015-04-30  1:35               ` Junio C Hamano
2015-04-26  6:49           ` [PATCH v5 2/5] setup: sanity check file size in read_gitfile_gently Erik Elfström
2015-04-28  6:02             ` Jeff King
2015-04-28  7:21               ` Windows path limites, was " Johannes Schindelin
2015-04-28 15:33                 ` Doug Kelly
2015-04-28 16:20                   ` Windows path limits, " Johannes Schindelin
2015-04-28 19:28               ` erik elfström [this message]
2015-04-29 15:42             ` Junio C Hamano
2015-04-26  6:49           ` [PATCH v5 3/5] t7300: add tests to document behavior of clean and nested git Erik Elfström
2015-04-26  6:49           ` [PATCH v5 4/5] p7300: add performance tests for clean Erik Elfström
2015-04-28  6:33             ` Jeff King
2015-04-28 19:36               ` erik elfström
2015-04-26  6:49           ` [PATCH v5 5/5] clean: improve performance when removing lots of directories Erik Elfström
2015-04-28  6:24             ` Jeff King
2015-04-28 20:31               ` erik elfström
2015-04-25  9:06 ` [PATCH v4 3/5] t7300: add tests to document behavior of clean and nested git Erik Elfström
2015-04-25  9:06 ` [PATCH v4 4/5] p7300: add performance tests for clean Erik Elfström
2015-04-25  9:06 ` [PATCH v4 5/5] clean: improve performance when removing lots of directories Erik Elfström

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

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

  git send-email \
    --in-reply-to='CAMpP7NY76Tj_=_6Evxvox20OmQ5LnNiK1j4VHLd0jKhRmci51g@mail.gmail.com' \
    --to=erik.elfstrom@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.