In bitbake fetch code doesn't handle some special characters like +, (gtk+ is decoded into gtk%2B) and gets the directory doesn't exist on the local drive, which is wrong.

So, that causes source mirror url doesn't work. Here is what Robert told in the mail list.

>   for a yocto talk to my local LUG later this week, i want to build
> a simple core-image-sato image for qemux86 and, for quite some time,
> i've kept a local download directory for tarballs, and taken
> advantage of it with this in all of my local.conf files:
>
> SOURCE_MIRROR_URL ?= "file:///home/rpjday/dl/"
> INHERIT += "own-mirrors"
> BB_GENERATE_MIRROR_TARBALLS = "1"
> # BB_NO_NETWORK = "1"
>
>   obviously, as i notice newer tarballs getting downloaded, i'll
> just copy them into ~/dl so it doesn't happen again.  works fine,
> except today with gtk+-2.24.8.tar.bz2 which, even after i made a
> copy of it in ~/dl, the build still *insists* on downloading it from
> download.gnome.org.
>
>   i don't see any obvious problem -- the checksum of the tarball
> appears correct, it's a regular file, the tarball downloaded is
> *exactly* the same as the one i've saved in ~/dl and yet, of all the
> tarballs i have stashed away there, that one is the *only* one that
> is downloaded each time.

  ok, i'm baffled and getting thoroughly annoyed here.  i started from
absolute scratch, configured to build for qemux86, then did

  $ bitbake -c fetchall core-image-sato

while pointing at my massive directory of tarballs which includes
gtk+-2.24.8.tar.bz2.  every required tarball is accessed (via symlink)
from my ~/dl directory, *except* for that incredibly irritating
gtk+-2.24.8.tar.bz2 tarball, which is downloaded by the "fetchall"
command *every* *single* *time*.

  i've verified that tarball is there.  i've verified its md5 and
sha256 checksums.  i'm out of ideas.

  what am i doing wrong?