Failure in TRANSLATE-PATHNAME on Windows

[Robert Goldman]

I received a bug report about ABCL failing ASDF tests on Windows. This is ABCL version 1.2.1, which I understand not to be the newest version, but seems to be what's commonly distributed to users.

Here are five key frames in backtrace:

17: (ERROR "Unsupported case in TRANSLATE-DIRECTORY-COMPONENTS.")
18: (SYSTEM::TRANSLATE-DIRECTORY-COMPONENTS (:ABSOLUTE "users" "dcooper8" "genworks" "cl" "tests" "asdf" "asdf-windows" "test" "preflight-checks") (:ABSOLUTE "Users" "dcooper8" "genworks" "cl" "tests" "asdf" "asdf-windows" :WILD-INFERIORS) (:ABSOLUTE "Users" "dcooper8" "genworks" "cl" "tests" "asdf" "asdf-windows" "build" "fasls" "abcl-1.2.1-fasl42-win-x64" "asdf" :WILD-INFERIORS) NIL)
19: (SYSTEM::TRANSLATE-DIRECTORY (:ABSOLUTE "users" "dcooper8" "genworks" "cl" "tests" "asdf" "asdf-windows" "test" "preflight-checks") (:ABSOLUTE "Users" "dcooper8" "genworks" "cl" "tests" "asdf" "asdf-windows" :WILD-INFERIORS) (:ABSOLUTE "Users" "dcooper8" "genworks" "cl" "tests" "asdf" "asdf-windows" "build" "fasls" "abcl-1.2.1-fasl42-win-x64" "asdf" :WILD-INFERIORS) NIL)
20: (TRANSLATE-PATHNAME #P"C:/users/dcooper8/genworks/cl/tests/asdf/asdf-windows/test/preflight-checks/preflight.abcl" #P"C:/Users/dcooper8/genworks/cl/tests/asdf/asdf-windows/**/*.*" #P"C:/Users/dcooper8/genworks/cl/tests/asdf/asdf-windows/build/fasls/abcl-1.2.1-fasl42-win-x64/asdf/**/*.*")
21: (UIOP/PATHNAME:TRANSLATE-PATHNAME* #P"C:/users/dcooper8/genworks/cl/tests/asdf/asdf-windows/test/preflight-checks/preflight.abcl" #P"C:/Users/dcooper8/genworks/cl/tests/asdf/asdf-windows/**/*.*" #P"C:/Users/dcooper8/genworks/cl/tests/asdf/asdf-windows/build/fasls/abcl-1.2.1-fasl42-win-x64/asdf/**/*.*" NIL #P"C:/Users/dcooper8/genworks/cl/tests/asdf/asdf-windows/**/*.*")
22: (ASDF/OUTPUT-TRANSLATIONS:APPLY-OUTPUT-TRANSLATIONS #P"C:/users/dcooper8/genworks/cl/tests/asdf/asdf-windows/test/preflight-checks/preflight.abcl")

Reading from the bottom, frames 22 and 21 show ASDF trying to translate a pathname for an abcl file to its fasl store. Then we move to the ANSI CL function translate-pathname which I believe should handle this case successfully.

[François-René Rideau]

Note the Users vs users case issue.
It's quite possible that the bug is actually in getcwd, truename and/or user-homedir-pathname having incompatible case normalizations, at which point the problem is somewhere else in UIOP.

[Robert Goldman]

Confirmed on ABCL 1.3.0

[Robert Goldman]

Replying to françois-rené rideau:

Note the Users vs users case issue.
It's quite possible that the bug is actually in getcwd, truename and/or user-homedir-pathname having incompatible case normalizations, at which point the problem is somewhere else in UIOP.

I don't have access to a Windows box, but I don't see anything hinky on Mac OSX, where the home directory is "/Users/rpg/," when I tested UIOP:GETCWD, TRUENAME, and USER-HOMEDIR-PATHNAME.

Why do you think this is UIOP?

[François-René Rideau]

I don't know where the error is, but whichever part of the software is feeding a downcased /users to translate-pathname is probably wrong. How come the source pathname has /users and not /Users? And why only in this configuration? I don't know, but it's worth examining, and it's probably a bug in ABCL, but not in TRANSLATE-PATHNAME itself

Note though that to reach this TRANSLATE-PATHNAME, a PATHNAME-MATCH-P must have returned T, so there's still a bug in ABCL, for which PATHNAME-MATCH-P and TRANSLATE-PATHNAME disagree.

[Robert Goldman]

Maybe someone with access to Windows could check TRUENAME and USER-HOMEDIR-PATHNAME to make sure there's no problem there.

Other than that, I'm having trouble figuring out how ASDF is finding the test systems, so it's hard to track down where the bad "users" string is coming from. The central registry is manipulated in script-support, and in run-tests.sh, which makes it a little hard to figure out. There's that test-source-registry-conf.d, but I'm not sure it's ever used. And script-support clears the source registry, but I'm not sure how it finds the test asds...

[Dave Cooper]

...
CL-USER(2): (user-homedir-pathname)
#P"C:/Users/dcooper8/"
CL-USER(3): (truename (user-homedir-pathname))
#P"C:/Users/dcooper8/"
CL-USER(4):
...

[François-René Rideau]

Dave Cooper ran the tests on ABCL and had more errors, in randomly-seeming different places.

I realized that all my pathnames in Linux were lowercase.

I renamed my ~/cl/ as ~/Common-Lisp/ and had failures with ABCL, in yet different and not reproducible places.

I created a temporary home in /tmp/Home and had yet different failures.

I suspect ABCL is doing an in-place downcasing of some strings at some point instead of a pure case-insensitive comparison or some such.

[François-René Rideau]

dcooper mentions that on Windows, he gets a lower case users in his *default-pathname-defaults*:

#P"C:/users/dcooper8/genworks/cl-engines/abcl-bin-1.3.0/"

On Linux, I get #P"/tmp/Home/common-lisp/asdf/" which is correct, and my test failures seem to be related to logical-pathnames, whereby too much is downcased.

[Dave Cooper]

I think the following should be returning uppercase U in ".../Users..."

CL-USER(1): (describe *default-pathname-defaults*)
#P"C:/users/dcooper8/genworks/cl-engines/abcl-bin-1.3.0/" is an object of type PATHNAME:

HOST NIL
DEVICE "C"
DIRECTORY (:ABSOLUTE "users" "dcooper8" "genworks" "cl-engines" "abcl-bin-1.3.0")
NAME NIL
TYPE NIL
VERSION NIL

CL-USER(2):

[François-René Rideau]

Dave further reports:

CL-USER(5): (uiop:getcwd)
#P"C:/users/dcooper8/genworks/cl-engines/abcl-bin-1.3.0/"

CL-USER(6): (java:jstatic "getProperty" "java.lang.System" "user.dir")
"C:\\users\\dcooper8\\genworks\\cl-engines\\abcl-bin-1.3.0"

So the JVM is doing too much or not enough, here. Sigh.
Then bugs in ABCL itself make for confusing error messages.

[Mark Evenson]

Ticket retargeted after milestone closed