My very first attempt at using ASDF version 1.661 on my system ended-up in the debugger on a file-error signaled by function truename.
The offending call came from function asdf::component-parent-pathname that contains a call to truename unwrapped in any condition handler although truename is required to signal errors. This seems to be the only such instance in asdf.lisp, all the other truename calls being wrapped inside a ignore-errors.
I fixed the situation by modifying asdf::component-parent-pathname this way:
(defun component-parent-pathname (component) (aif (component-parent component) (component-pathname it) (or (ignore-errors (truename *default-pathname-defaults*)) *default-pathname-defaults*)))
BTW, I would like to mention that in my CL system *default-pathname-defaults* is not a replacement for the process current working directory (which can be properly queried only through a call to getcwd). Thinking otherwise seems to me to be pretty clearly an unportable assumption unsupported by the ANSI CL standard. That ASDF seems to make that assumption troubles me seriously.
In fact I cannot figure out how I would explain to a naive beginning lisper on MS-Windows that *default-pathname-defaults* is an equivalent of the current directory when there is a potential of up to 26 simultaneous current directories on his OS (one per drive letter).
On the top of that the current working director(y|ies) is/are a process-level attribute and *default-pathname-defaults* being a special variable is most likely to have a thread-local binding at one point or an other, in some CL systems this could even be part of the initial thread bindings. How one reconciles these many independently evolving thread bindings with the single process-level attribute sure beat me!
Cheers,
Jean-Claude Beaudoin