CFPDF action="protect" ColdFusion could not delete the file

Question

I do the following:

<cffunction name="GenerateTemporaryDocument" access="remote" returntype="string">
        <cfargument name="Source" type="string" required="yes" >
        <cfargument name="Fields" type="array" required="yes" >

    <cfset Source  = "\#Source#" >
    <cfset pdfName = ".\Generated\#CreateUUID()#.pdf" >

    <cfpdfform action="populate"    
            source="#Source#"   
            destination="#pdfName#" 
            overwrite="yes">

    <cfpdfform action="populate"    
           source="#Source#"    
           destination="#pdfName#" 
           overwrite="yes">
           <!--- 
           some form fields that get filled 
           --->
    </cfpdfform>

    <cfpdf action="write" 
        source="#pdfName#" 
        destination="#pdfName#" 
        flatten="yes" 
        overwrite="true">

    <cfpdf action="protect" 
         source="#pdfName#" 
         newOwnerPassword ='xxxxx'
         permissions = 'AllowPrinting'>


        <cfreturn pdfName>

</cffunction>

I'd say 99/100 times, it works fine. But every so often, I get this error on the line for the protect command:

ColdFusion could not delete the file C:\inetpub\wwwroot\Generated\D6DBE4BD-AC16-2D87-C6CC1FDB990820C2.pdf.

Is there some obvious reason it would do this? If not, is there a way I can do a while loop and have cf wait for the file to become available?

Answer 1

FYI, I found a suggestion by Charlie Arehart & others at

https://community.adobe.com/t5/coldfusion/i-was-not-allowed-to-deleted-them-pdf-s-until-i-had-restarted-cf/td-p/2435410

From Charlie Arehart's first comment:

"You don't really need to create files with these CFPDF* tags

... 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.

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

... /Charlie (server troubleshooter, carehart.org)"

and a solution by MarkMetcalf along those lines.