File exist problem with dynamic Job Output Mask

According to the documentation one can use a dynamic folder name in the job output mask

The Job Output Mask may contain (dynamic) folder names, for example: ${document.metadata['Country']}\${template} .
The evaluated value of the Job Output Mask is taken as a path relative to the folder specified by the Job Output Folder (the next option in this dialog). The Job Output Folder must exist, but folders specified in the Job Output Mask will get created if they don’t exist.

I’m having a problem though when I make a proof print from the designer (File > Proof Print). My Job Output Maks is set to:

${document.metadata.printingHouse}\${document.metadata.postedShipmentNo}.${template.ext}

The first time I proof print everything works fine: the “printingHouse” folder MDS2 gets created and the pdf files are generated in that folder, just as expected.

However, the second time I try this, it fails.
image
I could live with Connect Designer not being able to overwrite any pre-existing pdf files (although an “overwrite existing files” flag in the Output Creation dialog would be a nice addition). But…
Even when I empty the folder before a second try, I still get the same error message. The fact that the folder MDS2 exists is apparently a problem for Connect Designer. And that is less acceptable. Imagine a scenario where a first run creates the MDS2 folder and file1.pdf in it and a second run would create file2.pdf. This would fail because MDS2 already exist, which seems rather absurd to me.

Is there a way to circumvent this issue?

Thanks.

Hello @b.degryse,

Can you let us know please in which version of the PlanetPress Connect Designer application the issue does occur?

Can you also let us know please which values are inserted in the Job Output Mask and Job Output Folder input fields on the Print Options page?

Hi Marten

Designer version 2021.1.1.6675 (not the latest, I know, but considering the deadlines I’m facing, upgrading is - unfortunately - not an option this year)

Job Output Mask: ${document.metadata.printingHouse}${document.metadata.postedShipmentNo}.${template.ext}
Job Output Folder: D:\Projects\VDP\pdf\Stock Books

Thank you for answering my questions.

Can you please check if the user account, under which you’re executing the print job, does have the required permissions to read and write to the folder on the D drive? The reason why I am asking this is because I couldn’t reproduce the error so far by using the same directory but using the C drive as drive instead.

(Executed the test via the PReS Connect version 2023.1 Designer application)

Of course the permissions are ok, otherwise it wouldn’t work on the first run either. And it’s just running on my own local pc under my own credentials. So yes, credentially-wise everything is ok.

I understand that the error java.nio.file.FileAlreadyExistsException: <pathToFolder> does occur when executing a Proof Print job via the Connect Designer and using (a) folder name(s) in the Job Output Mask input field. Please execute a Print job (CTRL+P) instead of a Proof Print job to avoid the error from occurring.

[internal reference: removed]

Thanks for the info, Marten.

As I mentionned in my original message, proof printing is indeed what I’m trying. So, it’s a well-known bug. Has this bug been solved in a more recent version of the Designer?

I’m using proof print because I use the designer on my personal desktop (not on the server) and that’s where I want to receive the outcome of the proof print too.
Print also wouldn’t work since the type of connection to get that working is not allowed in the company.

Hello @b.degryse,

I would like to inform you that the incident you are currently facing has been escalated to our R&D department and will be investigated [internal reference: SHARED-90617].

The workaround for the moment is to first remove the subdirectory, the subdirectory MDS2 in your case, too before executing a Proof Print job for the second time.

P.S. To prevent confusion I have removed the internal reference, which was referring to a Enhancement Request, from my previous reply.

Thanks for escalating the incident, Marten.

1 Like