Miguel Medalha wrote:
Did you consider sharing a directory from the machine running distiller and cifs-mounting it on the linux side to get ntfs behavior?
That is out of question. The Windows machines are graphic workstations which are not all connected all the time and the Distiller service is essential to the network.
I was under the impression that the Distiller app was running under Windows. If it isn't, it doesn't make much sense for it to expect NTFS filesystem semantics.
When all the pages have been produced, one of the graphics people places a special text file on a folder watched by Distiller and it begins to bulk process all the individual PS files:
[...]
The difficulty with the scripted solutions proposed here is that we cannot know in advance at what time this process will take place and what the number of pages involved will be.
Can't the trigger operation of placing the special text file be replaced by that person starting the script instead (perhaps click a button on a web page or something similar)?
At the end of each issue every minute counts. A watching process would have to poll the status of the workflow for several hours with very small intervals, which would be a waste of processor cicles. And not a very elegant thing to do, I feel.
While I wouldn't call it elegant, filesystem caching makes such things efficient enough that you'll never notice them running. If you need a script that looks for a file to appear or expands a wildcard in a directory, go ahead and use one as long as you can sleep for at least a few seconds in the loop. It's cheaper than having a person rearrange something.