I was not allowed to deleted them pdf's until I had restarted CF

[nikos101]

I have my CF server generate lots of pdfs but when I got to around 270 lying in a folder I was not allowed to deleted them pdf's until I had restarted CF,

any ideas why this could have occured?

[nikos101]

The funny thing now when I try to create a pdf I get the following error from colfusion

faultCode:Server.Processing faultString:'Unable to invoke CFC - ColdFusion could not delete the file C:\Inetpub\wwwroot\FLEX\bookingsystem\pdfToSend/OPT-000000-295.pdf.' faultDetail:'Check if another request or process is not using the file.'

Im trying to do this: I'm not trying to delete anyting:

  <cfset out =  GetDirectoryFromPath(
GetCurrentTemplatePath()
) & "pdfToSend/#arguments.ref#.pdf">

  <cfpdfform source="#source#"
    destination="#out#" action="populate"  overwrite="yes" 
    >
    <cfpdfformparam name="1" value="#arguments.fields._1#">
    <cfpdfformparam name="29" value="#arguments.fields._29#">
  </cfpdfform>

  <cfpdf action="write" flatten="yes" source="#out#"
    destination="#out#" overwrite="yes"> </cfpdf>

[nikos101]

The weird thing is is that the PDF is created fine, then the error is thrown and my following email code is not excecuted:

<cfmail type="html" to="#email#"
                from="#arguments.Email#"  subject="FX"
                        mimeattach="#out#"
               

[BKBK]

Coldfusion may be attempting to write to the PDF file while reading it for the email. Test with a named lock, as follows:

<cflock name="out_pdf_lock" timeout="10" type="exclusive">
      <!--- the pdf code goes in here --->
</cflock>

<cflock name="out_pdf_lock" timeout="10" type="exclusive">
      <!--- the mail code goes in here --->
</cflock>

[nikos101]

Tried that and no success

[nikos101]

Am so glad this problem is on my dev server , I really hope it doesn't occor on live

[BKBK]

Tried that and no success

Then perhaps this PDF process spawns 2 threads contending for one file.

<cfpdf action="write" flatten="yes" source="#out#" destination="#out#" overwrite="yes"> </cfpdf>

Use different file locations for the source and destination, and see what happens. If that still gives an error, then use a named lock for the 3 blocks, as follows:

<cflock name="out_pdf_lock" timeout="10" type="exclusive">
      <cfset out =  GetDirectoryFromPath(GetCurrentTemplatePath()) & "pdfToSend/#arguments.ref#.pdf">
  <cfpdfform source="#source#" destination="#out#" action="populate"  overwrite="yes" >
    <cfpdfformparam name="1" value="#arguments.fields._1#">
    <cfpdfformparam name="29" value="#arguments.fields._29#">
  </cfpdfform>->
</cflock>

<cflock name="out_pdf_lock" timeout="10" type="exclusive">
      <cfpdf action="write" flatten="yes" source="#out1#" destination="#out2#" overwrite="yes"> </cfpdf>
</cflock>

<cflock name="out_pdf_lock" timeout="10" type="exclusive">
      <!--- the mail code goes in here --->
</cflock>

[nikos101]

Thanks again, I tried the 3 locks while keeping the source and destination the same and I still get the same error. I'll now try seperate locations like you said

[nikos101]

It would be so Cool if I didn't need to keep saving these temporary pdfs on my server, just only have my editable ones made by the graphics Dept. I guess al the pdfparam stuff stops me using the cfdocument tag?

oh an using your different locations works thanks

[nikos101]

For some reason Jrun.exe in cf 9 keeps handles on some of my pdf's, even weeks after. Only after resarting cf9 do these get freed.

Help

[paule1234]

Was there any resolution to this problem?   We just upgraded from CF8 to CF9 a couple days ago, and it appears cfpdfform is locking files open and causing our code to error out.

Our sequence is to do a cfpdfform to fill in form data, then we do a cfpdf to flatten the same source/destination file with overwrite.  This worked perfectly in CF8, now we've got a serious problem with CF9.

The cfpdf error is:

ColdFusion could not delete the file D:\mysites\blabla\contract_509.pdf.
Check if another request or process is not using the file.

[nikos101]

I just do a different name for flatten, I don't bother with the ideal override

I feel your pain buddy

[BKBK]

paule1234 wrote:

The cfpdf error is:

ColdFusion could not delete the file D:\mysites\blabla\contract_509.pdf.
Check if another request or process is not using the file.

It is likely to be a bug. I once reported something similar, which Adobe later confirmed.

I am curious what would happen if you tried the following idea:

<cfset myFile = FileOpen("D:\mysites\blabla\contract_509.pdf", "read")>
status before fileClose() call: <cfoutput>#myFile.status#</cfoutput><br>
<cfif myfile.status IS "open">
   <cfset fileClose(myFile)>
</cfif>
status after fileClose() call: <cfoutput>#myFile.status#</cfoutput>

[paule1234]

If I put a cflock around the cfpdfform, the resulting file does not stay locked open.

However, the subsequent cfpdf flatten call still fails, whether inside a cflock or not.

I submitted bug 83365 on this issue.

[Charlie Arehart]

Folks, I don't see anyone suggesting one feature that may help here. You don't really need to create files with these CFPDF* tags if you don't want to.

For instance, as seems Paule's issue, if one tag creates something that then another would use (as his CFPDFFORM result then being flattened), you can use the NAME attribute (instead of destination) to indicate a variable to hold the output of an earlier step, and then use that variable in the SOURCE of a later step.

I do realize that some may want to create the files intentionally, but perhaps at least if you only do it on the last step, it may resolve his problem.

As for earlier notes saying that files remain locked even after the request is finished, that's not something I've seen or know anything more about.

Just throwing this variable idea out if it will help anyone.

/charlie

[paule1234]

Charlie,

I like the idea, but I'm looking at the CF9 docs on CFPDFFORM, and it doesn't appear to be able to output to a variable... there's no "name" parameter as there is in CFPDF.  There's a line in the docs that say:

"For forms created in Acrobat, you can write the output to a PDF file only."

Anyhoo, Adobe just emailed me a confirmation a little while ago confirming the bug, so hopefully it's fixed in the next update...

[Charlie Arehart]

Paule, while CFPDF has the NAME attribute, look closely at the CFPDFFORM docs and you'll see that the SOURCE can be a bytearray. Also, the XMLData can name a variable to hold its result. You can search for "variable" or "byte array" on that page to find more.

I'll leave it to you and others to dive in further. I'm no expert on the tags. I was just making an observation if it may be helpful.

/charlie

[MarkMetcalf · Accepted solution]

I'm late to the conversation, but I had the same problem with populating a PDF form with data, saving that PDF, then flattening the PDF.

Here's how I solved it in CF9:

<cfset path = "#GetDirectoryFromPath(GetCurrentTemplatePath())#doc\">
<cfset srcFile = "template\myPDFtemplate.pdf">
<cfset destFile = "yourPDF.pdf">

<!--- Using NAME instead of DESTINATION tells Coldfusion to create PDF in memory --->
<cfpdfform action="populate" source="#path##srcFile#" name="#destFile#">
    <cfpdfformparam name="field1" value="some value">
</cfpdfform>

<!--- Using the variable in the SOURCE tells Coldfusion to read PDF from memory --->
<cfpdf action="write" destination="#path##destFile#" source="#destFile#" flatten="yes" overwrite="yes" />

Hope this helps others.

Mark

[nikos101]

is this bad bug fixed in CF10??

[nikos101]

when using this code I get this error:

<cfset destFile = "yourPDF.pdf">

<!--- Using NAME instead of DESTINATION tells Coldfusion to create PDF in memory --->

<cfpdfform action="populate" source="#path##srcFile#" name="#destFile#">

    <cfpdfformparam name="field1" value="some value">

</cfpdfform>

faultCode:Server.Processing faultString:'Unable to invoke CFC - The string SUMMARY.pdf is not a valid ColdFusion variable name.' faultDetail:'Valid variable names must start with a letter and can only contain letter, numbers, and underscores.'

[nikos101]

ok, removed the . and its ok,

to add more fuel to the fire is is possible to do this without actually saving to disk?

	<cfpdf action="write" flatten="yes" source="#tempFile#"
	destination="#outFlat#" overwrite="yes"> </cfpdf>

and then sending it in an email?

[Charlie Arehart]

Nikos, I see two different answers to your question.

First, as for the CFPDF and writing to a file, you ask if there’s another option to “writing to disk”. Do you mean, perhaps, writing it to memory? If so, first note that the purpose of the CFPDF action=”write” is specifically to write to a file. If you don’t want to do that, there are other ways to get CFPDF results to a variable—but not using that specific tag/action combination.

For instance, if you had done some previous CFPDF action (in your code on that page), note that rather than have THAT code write ITS result to whatever file you point to here as tmpfile, you could have (in almost all cases) named a variable as the output (using NAME instead of DESTINATION). Again, I’m not talking about the CFPDF action=”write”, but any CFPDF tags you may have that preceded that to create the file that you’re pointing to in the CFPDF action=”write” SOURCE attribute. See the CFML reference for more on that, such as at http://www.cfquickdocs.com/cf8/#cfpdf.

Second, though, you say you want to “send it via email”. You’re talking about sending the flattened PDF, right? Well, you would need to “send” such a PDF by email as an attachment. And in most cases, you do that by pointing to a file, whether with CFMAIL’s MIMEATTACH attribute, or the CFMAILPARAM FILE attribute. So you do need a file as the result anyway. So I don’t think you really want to skip writing the file.

Make sense?

/charlie

[nikos101]

thanks charlie, the specific issue is that I cannot flatten the pdf with out the action being write