devbox@COMPUTEC The Computec development blog

ColdFusion 8 and Symlinks – Hell Awaits? (solved)

UPDATE: The issue seems to be fixed with ColdFusion Hotfix hf801-71648 (see technote kb403629). The fix is included in the Cumulative Hot Fix 2 for ColdFusion 8.0.1 (see technote kb403781). My bad - I thought I had deployed the hotfix when all I had in fact done was upload the zip-file instead of the jar. Epic fail. Anyway, the technote is a bit misleading as well - it's talking about Application.cfm path resolution when the same issue applies to cfinclude, too.
UPDATE 2: This hit us today again. I usually download the ZIP-Archives of the updates and just unzip then in place before restarting coldfusion. For some reason two of our five CF-servers decided to include chf8010002.zip into their classpath instead of the chf8010002.jar that was sitting right next to it. I cannot imagine how CF decides that a ZIP-file would be a valuable addition to its classpath, but only after I simply removed the original ZIPs and restarted the server, the JAR was correctly included and the annoying symlink resolving went away.

I recently stumbled over an issue when using symbolic links on a couple of ColdFusion applications. I intended to use symlinks to keep duplicate code between different applications to a minimum. I'm running Apache 2.2 with ColdFusion 8.0.1 on 64-bit Debian Etch. Each of our web-applications needs a "connector" while retaining an include with some site-specific config.

This is the intended directory layout

../foo/shared/connector/bar.cfm
../foo/mysite/myinclude.inc
../foo/mysite/connector symbolic link to -> ../shared/connector
../foo/mysite/bar.cfm symbolic link to -> connector/bar.cfm

../foo/mysite/ would be the web-root for my application. bar.cfm just reads <cfinclude template="./myinclude.inc">, myinclude.cfm reads <cfoutput>#now()#</cfoutput>.

Calling http://mysite/bar.cfm I get an error "Could not find the included template ./myinclude.inc." and a detail: "The error occurred in /var/www/.../foo/shared/connector/bar.cfm: line 1". Notice the path to the file that throws the error? ColdFusion seems to have resolved the symlink to its destination instead of executing the symlink in the location it was found just like it would have executed a physical file.

The webserver has no problem with calling this file via symbolik link - if I simply rename the symlink bar.cfm to bar.txt, I get the source code of bar.cfm (as this is not going through ColdFusion). And if I simply copy the physical bar.cfm over the symlink, all is well, too.

Webserver aliases wouldn't work in this case either, because they wouldn't parse the site's Application.cfc, as it's a different physical path. Symlinks would emulate the physical paths being present in different locations, though without actually having several physical copies. Symlinks would be extremely useful - if only they worked as intended (i.e. transparent, as they are for almost any other program). This is exactly the use case symlinks were made for - and the way they are handled by the filesystem.

I wonder what may be the reasoning behind this non-standard link-resolving of ColdFusion. Has anybody else experienced this unexpected behaviour and found some solution?

Be Sociable, Share!

•