Symbolic Links do not work for Application.cfm in CF10

Report · May 26, 2013

I have a Web, that use a symbolic link for centralized code.

The Application.cfm, stored in the original web-root, will not read from code

in the linked directory.

Thank you for your assistance.

Report · May 26, 2013

You're gonna need to provide a bit more detail here:

* OS

* how you created the link

* how you're calling in the code

* what the error message is

* have you verified the user CF is using has permissions to the files concerned

--

Adam

Report · May 26, 2013

Hi Adam,

thank you for your answer.

The web servers works under SuSE Linux 12.3, the link was first copied via a tar-archive

from the old server and then created new with "ln -s ../orgdirectory newdirectory".

It seems, that the Session-ID, defined in Application.cfm is not recocnized by cfm-templates

in newdirectory, which probably is stored in "orgdirectory".

There are several Error messages, that session-variables (SESSION.LANG for example) are

not defined. All these variables were defined in Application.cfm.

The Application.cfm is owned by the same user as the other cfm-Templates.

This code is identical functional at another server, working with CFMX7.

I had installed all patches, that offered by Adobe.

I'm frustrated.

Report · May 26, 2013

I made an additional test.

A <cfabort> in Application.cfm will cause a Termination, if I call a cfm-Template in the server-root, but not, if I call a cfm-Template in the linked directory (newdirectory as described above)

Report · May 26, 2013

Turn debugging on and look at the files listed in the "execution times" table. I suspect it will show a different - intermediary - Application.cfm being called.

--

Adam

Report · May 27, 2013

Adam,

it seems to be a bug.

The "Application.cfc/Application.cfm lookup order" in the ColdFusion Administrator seems not functional as expected. I did several tests and it happens not only at symbolic links. This happens on every subdirectory.

Am I wrong, when I expect, that the "highest" Application.cfm found in a tree should be executed?

Example:

/

Application.cfm

aaa.cfm

!-----------------------------------------!

! !

"subdir1" "subdir2"

bbb.cfm Application.cfm

ccc.cfm

Settings in the ColdFusion Administrator

Default order:

- aaa.cfm: should execute the Application.cfm in root (/) only.

- bbb.cfm: should execute the Application.cfm in root (/) only.

- ccc.cfm: should execute the Application.cfm in subdir2 only.

Until Webroot

- aaa.cfm: should execute the Application.cfm in root (/) only.

- bbb.cfm: should execute the Application.cfm in root (/) only.

- ccc.cfm: should execute first the Application.cfm root (/) and then in subdir2

In Webroot

- aaa.cfm: should execute the Application.cfm in root (/) only.

- bbb.cfm: should execute the Application.cfm in root (/) only.

- ccc.cfm: should execute the Application.cfm in root (/) only.

Am I wrong with this?

In my case, only "In Webroot" work as expected.

Torsten

Report · May 27, 2013

Yes, sorry, you are misinterpretting how the Application.cfc/cfm look-up works. CF will only ever execute ONE Application.cfm file: the nearest upstream one; where by "upstream" I mean it'll look in the current dir, then the parent dir, then the grandparent dir, etc.

The setting in CFAdmin means this:

* default: it'll traverse all the way to the root of the drive

* until webroot: it'll traverse only as far as the webroot

* webroot only: it'll only look in the current directory and then the webroot, but not the intermediary ones

But whichever option you employ, only ever the "nearest" Application.cfc or Application.cfm is used.

--

Adam

Report · May 27, 2013

Hi Adam,

thank you for your support!

Ok, I agree to that, that only one Application.cfm should execute.

But in the options "default" and "until webroot" an Application.cfm will never executed from templates

in subdirs. This works only with the option "webroot".

In my webs, I can do this workaround to select "webroot only" and place the one and only Application.cfm

in the webroot. This works fine now.

But it seems to be a bug in CF10, that there is no search sequence to upper folders. Do you agree with me?

As I explained, I did several tests, and with the options "default" or "until webroot" selected, an Application.cfm

in upper folders were never executed.

Torsten

Report · May 27, 2013

But it seems to be a bug in CF10, that there is no search sequence to upper folders. Do you agree with me?

No - I don't agree with you - because that would break pretty much every CF application on the planet. And we would have heard about that 😉 You're just doing something wrong, or your install is shagged (I suspect the former).

As I explained, I did several tests, and with the options "default" or "until webroot" selected, an Application.cfm
in upper folders were never executed.

OK, well I'm about to head out to the pub for lunch, so cannot look into this now. But depending on how comprehensive the "lunching" ends up being, I might have a look at this later today. Stay tuned.

--

Adam

Report · May 28, 2013

Adam Cameron. wrote:
OK, well I'm about to head out to the pub for lunch, so cannot look into this now. But depending on how comprehensive the "lunching" ends up being, I might have a look at this later today. Stay tuned.

OK, sorry for the delay: had too much beer at lunch so was neither use nor ornament for the balance of the day once I got home.

However I've completed my investigation / confirmation of how all this stuff works, and have written a blog article about it here:

http://cfmlblog.adamcameron.me/2013/05/applicationcfc-look-ups-and-linked.html

HTH.

--

Adam

Report · May 29, 2013

Hi Adam,

this explains everything!

I read your blog and understand right now,

that there is a difference between the system root

of coldfusion and the web root.

In my case, the webs are at a different location.

The system root of coldfusion is located at

/opt/coldfusion10/cfusion

and the web root is located at

/srv/www/<virtualhost>

Therefore I had misunterstood the options

in the Coldfusion Administrator.

With the option "webroot" everything works

as I expect.

Thanks once more for your support!

Torsten

Report · May 29, 2013

Cool. I think the misunderstanding is probably more on the part of Adobe using the term" web root" when they mean something else. The CF root and thr web root will seldom be the same directory, so their docs are misleading (or just wrong depending on how charitable one is feeling).

--

Adam

Report · Mar 08, 2014

This seems to be broken still/again, possibly due to a CF update, or possibly because it was always buggy in CF10. I have had no issues whatsoever in CF9 with the default lookup order.

I have the following directory structure ("webroots"):

/data/www/docroot

/data/mobile/docroot

/data/wwwdev/docroot

/data/mobiledev/docroot

And I symlink in the following cfc directories

/data/cfc

/data/cfcdev

Both www and mobile get /data/cfc and the dev sites get /data/cfcdev

Each of those docroots is a separate virtual server and I have setup the webserver connector to Tomcat.

Now, no matter which of the three lookup settings I try, the cfcs will not find an Application.cfc/Application.cfm

I read a similar issue early on in CF8 that was resolved with a patch to 8.0.1.

Any ideas?

Report · Mar 26, 2014

Don't know if this will help, or not. I was searching for a way to get TLS/SSL to work with CF10 built-in web server, and ran across this:

Note: To enable OS Symbolic links after switching to Tomcat, edit the context.xml file found in /cfusion/runtime/conf/ to add allowLinking="true" attribute to the context element.

HTH,

^_^

Report · May 26, 2013

Can you summarise the directory structure between the file you're calling and the Application.cfm you're intending to run. Also check whether there are any other intermediary Application.cfm files "upstream" from the file you're calling between that and your intended Application.cfm: if there is, your request will be running that insted of the one you want.

Another thing: if you output getCurrentTemplatePath() in the file you're calling, does it show the file being in the directory substructure of the symlink, or of its original location? I am guessing the former, but best to check.

--

Adam