A few days ago I was debugging an issue with Canvas when I ran across an interesting issue with CFFILE, action=upload. The user reported that the files he uploaded via the wiki were not visible. With some debugging, I found that files named foo.whatever ended up being upload to a folder with the same name as the filename, so instead of having the file end up here:
uploadsfolder/foo.whatever
They ended up here:
uploadsfolder/foo.whatever/foo.whatever
After an hour or so of debugging, I finally noticed something. The code to handle the uploads was specifying a path and filename for the destination. The docs for cffile/action=upload say that destination has to be directory. But apparently this has worked for quite sometime, except in ColdFusion 7.0.1 where the behavior was broken. This hotfix was released just to correct this issue.
This is probably just one more little facet of CFML I've forgotten, although I will say the docs should be updated to make this more clear.
Archived Comments
I remember when we had to go and fix this on a few dozen sites a few years ago :) Good times, good times. For my money, I don't know if it gets any better than nameconflict="makeunique".
If I remember right, a patch was also made to change back to previous behavior, all the way up to 8.
This reminds me of a problem I never resolved a while back. How to get <cffile action="readbinary" file="C:\#FileName#" variable="myFile" > to work when the file name has spaces in it assuming you can't rename the file.
CoolJJ
Eh? It works just fine for me. Example:
<cfset thefile = expandPath("./document copy.pdf")>
<cfif fileExists(thefile)>
<cfoutput>reading #thefile#</cfoutput>
<cffile action="readbinary" file="#thefile#" variable="bits">
</cfif>
This runs ok on my 8.0.1 install.
Aarrrggghhh! I was totally looking in the wrong place for the error. I hate it when I do that. Should have wrote a little test snippet like that and I would have figured it out. A url encoding error is what was screwing me up.
CoolJJ