Using Opus to copy files from one Win 7 64 bit client, to a Win 7 64 bit file sharing machine, is causing errors with a RIP (Raster Image Processor, i.e. hard core printer driver) - basically, we copy files to a network folder that polls this directory, the RIP sees these files and then prints them.
However, using Opus, and with files over 100Mb in size, the RIP kicks off prematurely and starts to render the file before the file is fully copied across, causing errors. (These files are often much larger than 100Mb).
In testing with vanilla windows explorer, this does not seem to happen ...the whole file gets copied, and THEN then RIP kicks off as expected.
We have also rarely seen this occur when copying very large files on the machine itself. from one folder to the RIP folder, but this is much less common.
Is there something we can tweak to stop this occurring? I am guessing this is some sort of difference in Opus copy vs Windows copy and holding handles on files or something....
When Opus copies files, it does not block other programs from opening and reading the destination files as they are being written. On the other hand, Explorer does.
RIP must be reacting to the files as soon as they appear, even though they are still being written to.
Can anything be done about that to stop it in this instance but leave the general behaviour?
No, there's no option to change how the files are written, unless you want to copy them using the same method as Explorer (there's a button to do that near the top of the Buttons and Toolbars forum).
Can RIP be configured not to act on files while they are still being (or were recently) modified? Or so that it does not open files shared for write access?
The problem can only arise if both Opus and RIP open the files with compatible sharing flags. Opus is happy to let other programs read the files as it writes them, since it doesn't cause Opus any problems. RIP must be flagging that it is happy for the file it opens to be written to at the same time (else the request to open the file would fail), but clearly it should not be doing that as it is causing a problem for RIP.
So, IMO, RIP is at fault here. It is opening the files in a way which does not make sense for what it intends to do with the files.
Ok thanks, I will chat to them and/or investigate the button option.
Cheers as ever for the prompt attention.