From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Robert Yang <liezhi.yang@windriver.com>,
Mark Hatle <mark.hatle@windriver.com>,
bitbake-devel <bitbake-devel@lists.openembedded.org>
Subject: Re: Filename too long
Date: Thu, 19 Jan 2017 10:21:02 +0000 [thread overview]
Message-ID: <1484821262.4367.424.camel@linuxfoundation.org> (raw)
In-Reply-To: <a8d463a0-f40a-afaf-c326-1f3bdffd49b7@windriver.com>
On Thu, 2017-01-19 at 14:13 +0800, Robert Yang wrote:
> Hi Mark,
>
> We have a local patch to fix the problem, I had sent it to bitbake-
> devel
> before, but not merged:
>
> https://patchwork.openembedded.org/patch/61321/
>
> Here is the updated patch in our bitbake:
>
> commit ebb1190c01a15fc6e91c9810c46313c3b3fb305c
> Author: Robert Yang <liezhi.yang@windriver.com>
> Date: Fri Nov 8 23:32:11 2013 +0800
>
> fetch2/git.py: fix the filename too long error
>
> When we use the PREMIRROR/MIRROR from the local disk, and if it
> is in a
> deep directory, for example, when len(path) > 255 (The
> NAME_MAX), we
> will get the "filename too long error".
>
> This is becuase we use ud.path.replace('/', '.') to change the
> path to
> the filename. We seldom see such a long url, but it is easy to
> produce
> it on the local machine.
>
> Another problem is that:
>
> file:///local/path
>
> will be converted into .local.path which is a hidden file by
> default.
Looking at the code in your patch, this second piece clearly isn't true
due to this code:
if gitsrcname.startswith('.'):
gitsrcname = gitsrcname[1:]
I also don't believe this patch is correct since we're meant to be
creating a filename, not a path and if you leave the '/' characters in,
it isn't a filename. I think we likely just need to truncate the path
to the last say 225 chars if its over length. The unique piece should
be towards the right hand end of the name.
Cheers,
Richard
next prev parent reply other threads:[~2017-01-19 10:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-18 19:02 Filename too long Mark Hatle
2017-01-19 6:13 ` Robert Yang
2017-01-19 10:21 ` Richard Purdie [this message]
2017-01-19 15:07 ` Mark Hatle
2017-01-19 16:05 ` Richard Purdie
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=1484821262.4367.424.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=bitbake-devel@lists.openembedded.org \
--cc=liezhi.yang@windriver.com \
--cc=mark.hatle@windriver.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 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.