Referring to the snapshot, the MainNew is self-replicating process that generating PDF file and reconciliation CSV file. It writes the reconciliation CSV file to a temporary folder named “csv” but I found that it intermediately hits error of creating directory at Send To Folder plug-in.
It seem like the Send To Folder plug-in of second thread wrongly detected the “csv” folder hasn’t created by the first thread.
What can I do to prevent it hit error?
Thank you.
Error code 183 is one of those “generic” error codes in Windows that could be caused by a number of different issues, not just by attempting to create an existing folder. Your logs don’t contain sufficient information to help us identify the cause of the issue.
I would suggest increasing the log level to All events with detail (in File | Preferences | Plugin | General) and then contacting our Support team with those logs in hand when the error occurs again.
1 Like
Is the E:\ drive a local drive? Because if it is a network one, that is the source of the problem. You’ll have to use UNC path.
1 Like
@hamelj : UNC paths are not recommended because of the latency they introduce due to the authentication process that takes places with every access to the path. Mapped drives are much more efficient.
1 Like
The E:\ drive is a local drive.
Think this is a bug in PP.
Have the same problem periodically with two other customers, it happens randomly when files are written to local disk.
I have tried to completely restructure the entire process, still the same problem.
I fixed it with a “All in one”, just pass the pdf through a template without doing anything to it, then the disk write works every time.
In my flow the disk error always came at the same place in the flow. Then I put in “All in one” and it stopped, but then the error moved somewhere else in the process. Then a new “All in one” etc. until I t stopped.
Of cause “All in one” delays the process time, but it works.
1 Like
@klaus.soerensen: if Workflow had issues writing files to folders (which is the very core functionality of the application), then we would receive literally thousands of reports about it… which we don’t.
Issues with writing files are usually due to one of two things:
- External factors: antivirus, wrong credentials, network latency, hardware failure, other application, etc.
- Conflict between multiple processes: one process attemps to write to a file while another one is doing the same (which can easily occur with self-replicating processes that write to statically-named files)
@davidwoo’s issue appears to fall into the first category since, from what I can tell, the file names are dynamic. That’s why I suggested that additional logging information might help us identify the culprit.
Also, your statement that the All-In-One fixes the issue is a bit puzzling: the original poster is attempting to write a CSV file to disk, so the AIO would be useless. Nor do I understand how it could fix your own issues. I would be interested in seeing an example of such a process.
1 Like
My psychic debugging powers tell me that this happens the first time of the day that the process runs. Why? The process is self-replicating and tries to write to a dynamic path which is based on the current date. Every process instance do the same thing when it gets to the output:
- Expand the dynamic path to its actual value
- Determine if the directory exists
- If not, create it
Step #3 is only executed once a day. The problem is that two processes do step #2 simultaneously and get to the same conclusion, that the directory doesn’t exist yet. So they both try to create the output directory, but only one of them can win this race.
The configuration should be reworked so that there is no race condition in creating the folder. This could be done, for example, by disabling self-replication on that process, or having another process run once at 00:01 AM and create the directory prior to the main one running (based on the assumption that it always run later in the day).
1 Like