From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: kusmabite@gmail.com
Cc: git@vger.kernel.org, msysgit@googlegroups.com, j6t@kdbg.org,
gitster@pobox.com, jrnieder@gmail.com
Subject: Re: [PATCH v2 5/6] msvc: opendir: handle paths ending with a slash
Date: Tue, 23 Nov 2010 21:16:44 +0100 [thread overview]
Message-ID: <4CEC212C.9060605@lsrfire.ath.cx> (raw)
In-Reply-To: <AANLkTimkPMCAmpobetAvWjcGDt+G_wMdX+cXaf9-Z_v9@mail.gmail.com>
Am 23.11.2010 20:48, schrieb Erik Faye-Lund:
> On Tue, Nov 23, 2010 at 8:31 PM, René Scharfe
> <rene.scharfe@lsrfire.ath.cx> wrote:
>> Am 23.11.2010 19:38, schrieb Erik Faye-Lund:
>>> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
>>> ---
>>> compat/msvc.c | 2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/compat/msvc.c b/compat/msvc.c
>>> index 199eb22..fdbfb70 100644
>>> --- a/compat/msvc.c
>>> +++ b/compat/msvc.c
>>> @@ -23,6 +23,8 @@ DIR *opendir(const char *name)
>>>
>>> /* check that the pattern won't be too long for FindFirstFileA */
>>> len = strlen(name);
>>> + if (is_dir_sep(name[len - 1]))
>>
>> Perhaps extend this thus, and handle multiple slashes?
>>
>> while (len > 0 && is_dir_sep(name[len - 1]))
>>
>>> + len--;
>>> if (len + 2 >= MAX_PATH) {
>>> errno = ENAMETOOLONG;
>>> return NULL;
>
> Sure, it could be done. But the reason why I didn't do that myself was
> that I got a bit worried about this being a slippery slope towards
> full path-normalization. FindFirstFileA() does handle non-normalized
> paths, as long as they are below MAX_PATH in length.
>
> I just didn't want to add a slash if there was already one there,
> which is something different than trying to fix the input-path.
>
> In other words, I'm not entirely sure if fixing up such a case is a
> task that belongs to opendir.
Okay; based on the subject of the patch I had assumed that opendir()
wasn't working at all on paths with trailing slashes.
René
next prev parent reply other threads:[~2010-11-23 20:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 18:38 [PATCH v2 0/6] win32-dirent Erik Faye-Lund
2010-11-23 18:38 ` [PATCH v2 1/6] msvc: opendir: fix malloc-failure Erik Faye-Lund
2010-11-23 18:38 ` [PATCH v2 2/6] msvc: opendir: allocate enough memory Erik Faye-Lund
2010-11-26 18:34 ` Junio C Hamano
2010-11-23 18:38 ` [PATCH v2 3/6] msvc: opendir: do not start the search Erik Faye-Lund
2010-11-23 18:38 ` [PATCH v2 4/6] win32: dirent: handle errors Erik Faye-Lund
2010-11-23 18:38 ` [PATCH v2 5/6] msvc: opendir: handle paths ending with a slash Erik Faye-Lund
2010-11-23 19:31 ` René Scharfe
2010-11-23 19:48 ` Erik Faye-Lund
2010-11-23 20:16 ` René Scharfe [this message]
2010-11-23 18:38 ` [PATCH v2 6/6] win32: use our own dirent.h Erik Faye-Lund
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=4CEC212C.9060605@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=jrnieder@gmail.com \
--cc=kusmabite@gmail.com \
--cc=msysgit@googlegroups.com \
/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 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 NNTP newsgroup(s).