As the subject says…
As per a previous email I got told they fixed this problem, and then a day later it was broken again. Now I am being told that this section of code in the ioc/binder.cfc WILL NOT WORK with sandboxing.
for(x=1; x lte arrayLen(arguments.locations); x++){
// Validate it is not registered already
if ( NOT structKeyExists(instance.scanLocations, arguments.locations[x]) ){
// Process creation path & Absolute Path
instance.scanLocations[ arguments.locations[x] ] = expandPath( “/” & replace(arguments.locations[x],".","/",“all”) & “/” );
}
}
The host is saying that the expandPath has a bug where if the arguments.location is null or blank, then it will return the ColdFusion/wwroot instead of the application root. This doesn’t make sense to me and I have tried to duplicate the sandboxed problem and not able to.
So anyone else out the able to confirm or deny this allegation by my host?
Btw they suggest this as a fix
instance.scanLocations[ arguments.locations[x] ] = expandPath( “/” ) & replace(arguments.locations[x],".","",“all”) & “”;
Yet this seems to cause more errors within the application further on.
I am stumped to get these guys to get their act together, they actually got this to work 2 days ago and when I pushed what the change was that was needed I was told it was a sandbox issue and wouldn’t tell me what it was. Now they are trying to tell me that they made this change to the code 2 days ago.
So far I have caught these guys out in 3 lies to me, and when I showed them the emails that contradicted what they were saying they then tried to lie again. These guys have been very good up till now, but I am beginning to think they are not as good as they claim to be.
Anyone else have any thoughts on this?
It appears to me that lets say we have securityService in the models directory, when starting the application it is trying to find this in
C:\coldfusion9\wwwroot\securityService.cfc
Instead of
D:\home\accoutname\wwwroot\model\securityService.cfc
Which makes no sense to me at all.