I’ve been making a couple of modifications to dmFile, but have generally come back to the default dmFile.cfc included in Core. However, I have a strange problem in that when I use the Webtop to upload a file, I’m getting three copies of the file. The original, and then xxx1, xxx2, xxx3. The database stores the xxx3 version.
The parameter for ftSecure=“false” and in server specific vars after Init, I have the following:
<cfset application.fc.lib.cdn.setLocation(name="publicfiles", cdn="local", fullpath="E:/inetpub/wwwroot/farcry/projects/clientproj/www/sites/default/files",urlpath="/sites/default/files") />
<cfset application.fc.lib.cdn.setLocation(name="privatefiles", cdn="local", fullpath="E:/inetpub/wwwroot/farcry/projects/clientproj/www/sites/default/files",urlpath="/sites/default/files") />
Where should I be looking to try to debug why I might be getting the multiple, duplicate upload?
PS. I’m running Adobe Coldfusion 11 on Windows Server with MS-SQL Server on FC 7.2.5
1 Like
A long shot but are you doing some server side validation with
<ft:serverSideValidation /> ?
I’ve recently discovered that this causes the 3 file versions to be created.
Hmm, I’m not sure how validation would affect the file writes… Is there something particular about your extended dmFile, e.g. custom properties that also have validation, or does this also happen with core’s dmFile?
At a guess I think there could be weird behaviour if the publicfiles and privatefiles directories set to the same location. Usually they are supposed to be different locations, where the privatefiles is somewhere outside the webroot. The purpose of privatefiles is so that draft documents aren’t publicly available, but if you don’t want that feature then you could override the status property for dmFile and set the default value to approved.
Could you try separating those two locations and see if that fixes it / changes the behaviour?
@phillipjrasmuss - No, I don’t think I am… certainly not in my project dmFile.cfc. Is there anywhere else that I should look to expect weirdness? This is still a pretty basic install.
@justincarter - I copied the core dmFile to my project packages directory and set the project’s extend property to farcry.core.packages.types.types
So, modifying the property ‘status’ to be approved resolved one issue I had a question with but couldn’t understand which was why my files always seemed to wind up in my ‘securefiles’ instead of my ‘publicfiles’. That now seems to work more as I would have expected.
However, modifying my serverVarsAfterInit as follows:
<cfset application.fc.lib.cdn.setLocation(name="privatefiles", cdn="local", fullpath="E:/inetpub/wwwroot/farcry/projects/clientProj/www/sites/default/files", urlpath="/sites/default/files") />
<cfset application.fc.lib.cdn.setLocation(name="publicfiles", cdn="local", fullpath="E:/inetpub/wwwroot/farcry/projects/clientProj/publicfiles", urlpath="/sites/default/publicfiles") />
I am still seeing 4 files writes to the public files directory.
I think you should discount my suggestion. This occurred for me when I had a custom validation function on the on a custom type during a custom form submit.
Do you have a custom edit function? Is there a webskin/dmFile/edit.cfm anywhere that might be overriding the core function?
No, I’ve tried to be pretty minimally invasive about this.
/inetpub/wwwroot/farcry/projects/clientProj/webskin/dmFile/
–displayPageStandard.cfm
–insertHTML_download.cfm
–mobilePageStandard.cfm
–tabletPageStandard.cfm
–webtopBody.cfm
No dmFile directory in /inetpub/wwwroot/farcry/plugins/farcrycms/
/inetpub/wwwroot/farcry/core/webskin/dmFile
–displayPageStandard.cfm
–insertHTML_download.cfm
–mobilePageStandard.cfm
–tabletPageStandard.cfm
–webtopBody.cfm
Interestingly enough, in an attempt to walk back this problem, I removed the dmFile.cfc from the project package and commented out the modifications in the serverVarsAfterInit.cfm file. I’ve also isolated this website in it’s own Coldfusion 11 server instance and restarted that instance. The CMS still was uploading the original + 3!
So, I went ahead and tested two other projects on this same server and realized the problem is happening in those as well. Could it be that somehow there is some type of javascript that is essentially being called 4 times to upload the file?
Is this the kind of thing that might get resolved if I was to restart Coldfusion for all the different instances on this machine? Would upgrading core to 7.2.6 make any difference?
I am hoping that this next clue will give you guys enough of a hint to help me either resolve the issue or roll it back somehow.
I attempted to upgrade CORE from 7.2.4 to 7.2.6. It worked for a couple of our sites, but we had trouble with other sites. I basically followed these steps:
- Stop Each Adobe ColdFusion Instance
- Stop each IIS website
- Stop IIS
- Rename CORE to CORE OLD
- Rename farcry-core-7.2.6 to core
- Restart IIS
- Restart each website
- Restart Each Instance of Adobe ColdFusion.
As I mentioned, the upgrade didn’t work properly,so I basically repeated the process,except 4 and 5 were different as required.
Anyway, here’s the clue:
BEFORE we followed these steps and upgraded from 7.1.x to 7.2.4, dmFile seemed to work fine.
Since then, we’ve noticed the problem that is the subject of this ticket. As indicated in my message of 30 June, the problem was when uploading file FILENAME.pdf, the server would store FILENAME.pdf FILENAME1.pdf FILENAME2.pdf and FILENAME3.pdf. The database record would have FILENAME3.pdf.
Now after this weekend and my attempt to upgrade, dmFile is now uploading the original file + 7 copies. The multiples have increased!
I really hope you guys can help me nail this one down. We tried poking under the hood of core and webtop, but we couldn’t figure it out.
-Phil
Hi Phil,
I’ve just given it a test by downloading the latest Core Comminuty zip from the FarCry Core site and doing a basic install using the Barebones skeleton.
I can confirm that when uploading a file in a draft dmFile object it creates the original + 3 files. When approving the object it moves the “filename3” version of the file from /securefiles to /files.
Definitely a core bug that needs to be investigated 
cheers,
Justin
Hey, I’ve got some time to investigate this tomorrow, but this stuff can be pretty tricky. Can someone give me a couple pointers on where to start?
Would this be in
/core/webtop/façade/fileupload/upload.cfm
/core/webtop/façade/jqueryUpload/upload.cfm
Is there anything that might be gleaned from the seeming second increase in file uploads after my failed upgrade attempt?
-Phil
Hey Phil, sorry I’ve been swamped. I haven’t tried to debug it yet but I think it’s unlikely that the /webtop/facade/fileupload/upload.cfm would be the cause of the issue – it’s probably something related to the file object workflow and the CDN lib file handling.
It would be worth checking the Git file history on packages/formtools/file.cfc and /packages/cdn/local.cfc and /packages/lib/cdn.cfc for recent changes, something in those commits might give away the cause.
I’m probably a couple of weeks away from having enough time to investigate it myself!
This issue has now been resolved, it was caused by a couple of separate issues;
https://farcry.jira.com/browse/FC-3081
https://farcry.jira.com/browse/FC-3082
It’s fixed in the head of p700, p710 and p20. Tagged releases to follow next week, in the meantime please let me know if you have any issues
1 Like
We updated on Sunday and the issue is resolved. Thanks Justin!
1 Like
