[armedbear-devel] Spaces in pathnames (jar:file:/x/y/z/a space/...)

[Theam Yong Chew]

On 2/17/11, Alessio Stalla <alessiostalla at gmail.com> wrote:
> On Wed, Feb 16, 2011 at 5:16 PM, Mark Evenson <evenson at panix.com> wrote:
>> On 2/16/11 14:34 , Theam Yong Chew wrote:
>> […]
>>>
>>> Sorry Mark, I was going to add some more clarification to my original
>>> email, but you were too quick to reply! The above error message was
>>> actually slightly different from how I originally stumbled on the
>>> problem, which looked somewhat like this:
>>>
>>> [1] CL-USER(1): (load
>>> "jar:file:/home/tyc20/Dropbox/temp/a%20space/hello.jar!/hello.abcl")
>>> #<THREAD "interpreter" {12C9557}>: Debugger invoked on condition of
>>> type FILE-ERROR
>>>    Loadable FASL not found for
>>> 'jar:file:/home/tyc20/Dropbox/temp/a%20space/hello.jar!/hello.abcl' in
>>> 'jar:jar:file:/home/tyc20/Dropbox/temp/a%2520space/hello.jar!/hello.abcl!/hello._'
>>> Restarts:
>>>    0: ABORT Return to debug level 1.
>>>
>>
>> […]
>>
>>> So to clarify, it wasn't a "Failed to create URI" error, but a
>>> "Loadable FASL not found" error.
>>>
>>
>> It looks like you might have encountered a more serious problem with our
>> classloader.  Can you mail me a copy of the failing jar file?
>
> Notice the %2520 in the failing path: "in
> 'jar:jar:file:/home/tyc20/Dropbox/temp/a%2520space/hello.jar!/hello.abcl!/hello._'"
> It looks like something is URI-encoding the already-URI-encoded
> pathname, replacing the % in %20 with %25 (thus obtaining %2520).
> I don't think this has anything to do with the classloader, but I may
> be wrong here. Generally, we might need to distinguish between
> URI-escaping Pathname constructors (for strings coming from the
> outside world) and non-URI-escaping constructors for use by ABCL
> internals.
>
> Bye,
> Alessio

Hi everyone,

I had a quick look at the source over last week.  I'm not
completely confident if the attached patch fixes it, or if I've broken
anything else...  I'm also not sure if I'm running the unit tests
properly, but at least the number of failures hasn't gone up!

According to my understanding, truename already has some uriEncoding
logic in it (which I didn't quite follow), so it seemed to me like the
second uriEncode is the redundant culprit. Am I right?

Yong.
-------------- next part --------------
Index: src/org/armedbear/lisp/Load.java
===================================================================
--- src/org/armedbear/lisp/Load.java	(revision 13229)
+++ src/org/armedbear/lisp/Load.java	(working copy)
@@ -153,7 +153,6 @@
 
         if (Utilities.checkZipFile(truename)) {
             String n = truename.getNamestring();
-            n = Pathname.uriEncode(n);
             if (n.startsWith("jar:")) {
                 n = "jar:" + n + "!/" + truename.name.getStringValue() + "."
                     + COMPILE_FILE_INIT_FASL_TYPE;