Ah right, shared hosting. :-( Forgot. (And yes, those really are tragic replies you're getting from them.)
Here's one more simple possible explanation and fix. It could be that while you were uploading the file, someone requested it right while it was being uploaded, which would have involved a delete of the old and placement of the new. But CF could have cached internally the fact that that url resulted in a 404. (This is a bug that was t o have been fixed in 7.02,though.) Again, clearing the template cache should help, but since you can't do that, try this. You say you upload the file again, and it still fails. Well, some ftp clients will set the date/time for the uploaded file to be that which was set for the file on your local environment (before uploading it, as opposed to setting the uploaded file's date/time to the time of the upload). Your link with the screenshot of the directory list is not working now, so I can't see what it says. But anyway, try to get the file date/time to change on the server to a date/time later than whatever it is now for the file you're trying you read. You want to cause CF to detect that the file has changed, so that it will pick it up and reload it (unless the "trusted cache" setting is on in the Admin, which is not likely in a shared hosting situation). If you don't know how to get your client to set that on the upload, then instead edit the file on your local machine so that its date is updated, and then upload it. If that's not it, or you're not convinced to try it, I'd go back to asking them to clear the template cache. I realize that with their less-than-supportive answers so far, you don't have much hope they would even click that simple button as a test for you. But I don't think you should give up so quickly on getting this important diagnostic info. Can you at least ask them? And then run your tests immediately after? They may be willing (if you knew the Admin password, you could call the Admin API yourself, btw, without needing to press that button, but without the admin password, you cannot do that). It could be that these things have no connection at all to your problem. It is indeed a curious one and I'll look forward to hearing how you solve it, if ever. /charlie PS if you want to read more about the problem of 404's being cached, which was to have been fixed in 7.02, Steven Erat had written about it here: http://www.talkingtree.com/blog/index.cfm?mode=entry <http://www.talkingtree.com/blog/index.cfm?mode=entry&entry=88BDF4E4-50DA-05 59-A023C957D70CD2EC> &entry=88BDF4E4-50DA-0559-A023C957D70CD2EC BTW, he noted that the problem could also happen if the CF template in question was being accessed over a UNC path. Since you're on a hosted server, you can't know if that's the case (in terms of how your file location appears relative to the CF server), but it's possible that it is on a UNC path from the server. Here's his entry on that issue: http://www.talkingtree.com/blog/index.cfm/2005/7/27/UNC4CFMX From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf Of Ryan Sabir Sent: Monday, June 22, 2009 8:55 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: CF8 "file not found" strangeness Thanks Charlie, This is the most frustrating thing about this issue. It's on a shared server at WebCentral so I have no access to the CF Administrator. I tried poking around the file system using CF but they have security turned on so I can't see the config files. Normally yeah I'd be playing around in the config files and cache directories looking for permissions issues but at the moment I'm just trying to get them to admit there is a problem. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
