FWD » Core Development » Conversion Tools

If I attempt to convert a project (e.g. Hotel), but the ./abl folder is a symlink, then the conversion fails with:

     [java] EXPRESSION EXECUTION ERROR:
     [java] ---------------------------
     [java] throwException(err)
     [java] ^  { Invalid basepath! basepath = ./abl; pkg = abl; [BLOCK id <360777252865> 0:0] }
     [java] ---------------------------
     [java] EXPRESSION EXECUTION ERROR:
     [java] ---------------------------
     [java] relpkg = execLib("rel_pkg_path")
     [java]          ^  { Expression execution error @1:1 }

I had another customer project fail exactly the same, but with different error feedback (#10981).

There are no issues when the symlink points to a folder in the ~/gcd/hotel_gui directory, but the problem appears when it is part of another folder that is outside ~/gcd/hotel_gui.

1. home = /home/ddf/gcd/hotel_gui and filename = abl/activate-rooms-dialog.w
2. abnormal.getCanonicalPath() = /home/ddf/gcd/abl/activate-rooms-dialog.w
3. new File(home).getCanonicalPath() = /home/ddf/gcd/hotel_gui
4. absolute.startsWith(home) = false
5. filename is returned

The issue? abnormal.getCanonicalPath() = /home/ddf/gcd/abl/activate-rooms-dialog.w follows the symlink target instead of preserving it.

1. home = /home/ddf/gcd/hotel_gui and filename = abl/activate-rooms-dialog.w
2. Path homeRoot = Paths.get(home).toAbsolutePath().normalize();
3. Path inputFilename = Path input = Paths.get(filename);
4. normalize the inputFilename
5. inputFilename.startsWith(homeRoot) => relativize(inputFilename) and return "." + File.separator + inputFilename
6. return the filename if nothing happened

I ran a Hotel_GUI conversion and it worked properly, I will commit the changes soon.

Rebased 11156a to latest trunk/16752, the branch is now at revision 16753.

3 MAJOR, all in normalizeFilename, all from dropping canonicalization:

• Uncanonicalized home breaks the ticket's own scenario. SymbolResolver.pkgExists() feeds canonical (symlink-resolved) paths from exists() into the two-arg overload whose home is now lexical-only. With basepath="./abl" or oo-skeleton-path="./abl/skeleton" symlinked, the containment check fails and a dotted filesystem path lands in the normalized-path annotation. The challenger found basepath="./abl" and oo-skeleton-path="./abl/skeleton" are real configured values in metacom-family projects, and that p2j is a symlink in 5 of 5 configured projects. Hotel_GUI — which uses a real ./skeleton/ dir and has little OO code — plausibly explains why this wasn't caught.
• Relative filenames now resolve against home, not CWD. pkgExists() line 10179 passes an already-relative "./abl/src/..." into normalizeFilename(basepath, ...), producing <cwd>/abl/src/abl/src/.... It still passes startsWith, so the basepath is silently never stripped. Verified with a compiled old-vs-new harness.
• "." → "./" for the project root. relativize() returns an empty path, so Configuration.withFileProfile()'s ".".equals(path) sentinel stops firing and startsWith("./") then matches every artifact — multi-profile conversions get the wrong profile.

Alexandru Lungu wrote:

Findings:

1. Major, BuiltinVariable.getValue: {&FILE-NAME} still follows the symlink before calling normalizeFilename() (it uses getCanonicalPath()). With ./abl pointing at /data/src, the result is "src/x.p" instead of "x.p", and that wrong value ends up in the converted code. This isn't new, but it's exactly the layout the ticket is meant to support. The fix is to pass getAbsolutePath() instead, and to check that the name starts with basepath before cutting it off.

This one especially is concerning, I found more than 1 call of normalizeFilename() that uses getCanonicalPath(). ALl of those should be fixed to avoid this in the future and have them use getAbsolutePath() as mentioned.