After much banging around against issues involved in merging PATHNAME objects when the defaults points to a JAR-PATHNAME, I think I am finally converging on a solution. I have [committed a design document][1] that describes my approach. The main user visible result here would be the successful location and retrieval from the network of the JNA component necessary for loading CFFI.

[1]: http://trac.common-lisp.net/armedbear/changeset/14172

The gist of the problem lies in that on non-Windows, the default DEVICE component is NIL, which when merged with a JAR-PATHNAME which represents the filesystem location of the jar archive in DEVICE, results in some rather bad interactions.

At the top of problem, on non-Windows when the defaults contain a JAR-PATHNAME:

1. (truename #p"/") fails.

2. Loading ASDF systems from jar files which declare dependencies on other ASDF systems will fail.

My proposed solution is to:

1. On non-Windows, TRUENAME for a non-JAR-PATHNAME will set the DEVICE of the result to :UNSPECIFIC.

2. Treat a JAR-PATHNAME as implicitly having a different HOST from normal file PATHNAME, so that the result of a merge won't fill in a DEVICE with the wrong "default device for the host" in the sense of the fourth paragraph in the [CLHS description of MERGE-PATHNAMES][2] (the paragraph beginning "If the PATHNAME explicitly specifies a host and not a device…").

[2]: http://www.lispworks.com/documentation/HyperSpec/Body/f_merge_.htm

My (uncommitted) patches seem to resolve all the problems, and work on both Windows and non-Windows. I still have two remaining ANSI failures that the changes introduced, involving the value of *COMPILE-FILE-TRUENAME* for which I need to rewrite the form which the compiler dumps pathnames from #p"/foo/bar" to the #p(:directory (:absolute "foo") :name "bar") form. Somehow, the new form isn't being read correctly (Erik I could use your advice here).

In addition, since namestrings are no longer always roundtrippable as they discard an :UNSPECIFIC DEVICE, I've had to change a bit of code in the compiler and the Pathname implementation which assumed otherwise.

A cleaner solution would probalby have been to actually populate the HOST field with a type nonce, like SBCL does. But we already use HOST to store information for a URL-PATHNAME. And given the reality that we should release an abcl-1.1.0 as soon as realistically possible, when I estimated that going down this route would change much more code I opted for the current solution where we take a cut at "Do What I Mean" reasoning we could potentially retrofit this with HOST containing various HOST forms for abcl-1.2.x if enough objections were raised.

Comments solicited.