>>Ah. I was under the impression you were transferring millions of files weekly, and on rare occasions you would get errors on *random* files. If the errors happen only to one file name, and you have a secondary process on the lookout for that particular file name it's pretty certain that's the cause.
>
>Yes, but on various other directories where the process I am doing deals with one specific file in some targeted directories.
>
>>In that case the .TMP file approach should work. But you'd have to make sure your file copy operation to that .TMP file is synchronous and run the rename only after it's finished.
>
>Yes, that is what it is.
>
>>In the past I've run into occasional errors renaming files or folders on Samba volumes. But if you're working against a good-quality NAS that's designed for Windows compatibility, you should be OK.
>
>Yes, and if it's not, we'll escalate that to network engineers.
An aside - if the NAS has dedupe enabled it would be even more elegant to use a native call. That would not touch the file at all, it would just add a pointer in the metadata. The underlying file would never be locked, and would already exist, so it would be immediately available to the secondary process. The contention issue would never arise.
Regards. Al
"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov
Neither a despot, nor a doormat, be
Every app wants to be a database app when it grows up