Our production environment is experiencing a random bug that is very difficult to reproduce. Every now and then (about 1 in 100), when our customised code saves out a PDF, it fails to create the PDF it was supposed to and instead overwrites a random PDF in the user's Documents folder, preserving only the filename. To be clear, nothing at all in our customised code goes anywhere near the Documents folder.
This is the snippet of code which saves the PDF:
FDKPropValsT setPDFVal = F_ApiGetSaveDefaultParams();
IntT iPropIndex = FDKApiGetPropIndex(&setPDFVal, FS_FileType);
setPDFVal.Val()[iPropIndex].propVal.u.ival = FV_SaveFmtPdf;
F_PropValsT *returnProps = NULL;
savedDocId = F_ApiSave(tgtBookId, PDFFileName, &setPDFVal, &returnProps);
Unfortunately due to the difficulty in reproducing this bug, I have not yet had it occur while debugging the program, so I haven't been able to inspect the input paramaters, returned doc id or return props when the bug occurs. However, I am confident the input parameters are correct, because I have tested changing tgtBookId to 0 and this is handled. Also as you will see in the proceeding screenshots, the correct PDFFileName is being passed to Distiller (nothing to do with Documents).
Calling the above code executes Distiller (presumably the FDK does this), which creates the PDF. This is what Distiller looks like when everything is normal and the PDF is created:
And this is what Distiller looks like when the bug occurs:
As you can see, the PDF File has .LOG extension instead of .pdf. What's more concerning though is the size of the source file is 0 bytes. I can only assume that the source file (S15_0322_v24.tps) is created by the FDK, because our customised code does not create this file, and the only thing we pass to F_ApiSave is the book id. I assume the FDK creates this temporary file based off the book id and passes it to Distiller, which makes me think this is a bug either with the FDK or with Distiller. The most concerning part of all however, is that even though the Distiller log says "No PDF produced", it has now actually overwritten a random PDF in the user's Documents folder! The PDF is automatically opened in Acrobat, which never happens when the correct PDF is made as in the first screenshot.
This has only started happening since we recently updated all of our hardware and software to the following:
Microsoft Surface Pro (2017)
Windows 10 Enterprise Version 1703 (64-bit)
Adobe FrameMaker 2017 Version 22.214.171.1240
Adobe Acrobat Pro 2017 Version 2017.011.30066
Adobe Acrobat Distiller Professional Version 17.11.30059238004
Previously we were running Windows 8, FrameMaker 11 and Acrobat Pro XI.
My questions are:
1) Is this issue familiar to anyone?
2) How is the temporary *.tps source file being created? Does the FDK create it? How is it getting a size of 0 bytes when this bug occurs?
3) When Distiller gets a source file with 0 bytes, how is it overwriting a random PDF in Documents with all the contents of the FrameMaker book? There is no mention of Documents in our customised code, or in the Distiller logs. Documents does however seem to be the default Save To path in Acrobat - the only correlation I can find, and the 'random' PDF happens to always be the last opened PDF in Acrobat.
I hope someone is able to help, as sooner or later it's going to overwrite someone's really important PDF.
YES, I've had this problem for years, and it still drives me nuts! (And it's overwritten some pretty important PDF files.) We just upgraded to FrameMaker 2017 and Acrobat DC, and it overwrote some random PDF file on my system on the very first book PDF I generated...
We experience the same thing using FM 12 version and previously FM9 version. Seems random and you never know when it is going to happen. Anyone get a solution to this please share. I have tired many things. Nothing seems to fix it.
Also happens in FM2019.
It seems more likely to happen for the first PDF written after restarting the computer.