Strange behavior with ColdFusion ExpandPath() when using Symbolic Links
ColdFusion, Technology, LinuxI was playing around with the Quicksilver framework last night, and for some reason it was unable to find and instantiate my CFCs properly. After digging into the framework a bit and determining where it was breaking, I discovered something strange about the way that ColdFusion interprets ExpandPath() when it exists in a directory that is defined as a symbolic link. I am not sure if the same behavior exists on Macs, but I would imagine it does. If someone could confirm that to be the case, I would be interested.
For starters, I usually have a 'www' directory in my user home directory. This way when I pass my user profile around from distro to distro, my development work is included in my home directory. For ease of configuration I typically have a symbolic link in my OS that points /www/ ---> /home/dshuck/www/. Then when I am creating a new web project called 'davescode', I would put it in /home/dshuck/www/davescode, but my Apache config would usually point to /www/davescode. For the past several years, this approach has worked will for me. That is until last night when experimenting with Quicksilver.
When Quicksilver loads, it creates a list of service CFCs in the the application in such a way that if I had Foo.cfc in a directory 'com' in the root of my davescode site, it would look like /home/dshuck/www/davescode/com/Foo.cfc. When I initted the application, I was getting an error that it couldn't find the CFC home/dshuckcom/Foo.cfc. Essentially what was happening is that it was getting the full path of the CFC and replacing the path to the root of the site with "". In a perfect world the value of the path after the string replace would have looked like com/Foo.cfc. Unfortunately that was not so. Here's why!
I put a test file called path.cfm in the root of my davescode site that considted of the following:
<cfoutput>#ExpandPath("./")#</cfoutput>
<br/>
<cfoutput>#ExpandPath("/")#</cfoutput>The result was very surprising!
/home/dshuck/www/davescode/ /www/davescode/
For some reason when you do ExpandPath("/") it looks at the symbolic link path, but when you do ExpandPath("./"), it looks at the true file path. For the life of me, I can't think of why that would be. If anyone has an explanation, I would be all ears!
(I'm just interpreting what I read here: http://ss64.com/bash/ln.html).
Given the symbolic link is just "redirecting", then expanding the path "./" kinda makes sense to resolve to the actual directory. Kinda. Why it doesn't do the same for "/"? Dunno.
What happens if you use a hard link?
--
Adam
This is what I get when I try to create the hard link:
$ sudo ln -d /home/dshuck/www /www
ln: creating hard link `/www' => `/home/dshuck/www': Invalid cross-device link
Because I have my /home mount point partitioned on a separate place than /, it is effectively 2 devices even though they exist on the same physical HD. Apparently hard links can only exists within a single device.
--
Adam
For example if you request foo.site.com/app1/a/test.cfm
You have the webroot for this subdomain set as /home/foo_site_com/www/app1/public/
The main webroot configured for apache when you setup JRun is set to /home/jrun/www/
expandPath("./") => /home/foo_site_com/www/app1/public/a/
expandPath("/") => /home/jrun/www/
btw, it's super hard to read the grey on grey on the comment form :(
Loading....