For those of you who have or are contemplating an upgrade to your Unix operating system, you should be aware of a problem that arises when you do so.
When Mlink transfers a file, by default it uses a "temporary receive file" until the transfer is completed. It then renames the temporary file to it's permanent name. In order to prevent temporary file name conflicts, Mlink uses a unique numeric naming convention. This name is derived from the 5 left justified characters of the Unix process ID of the process transferring the file. This scheme worked fine since the process ID was only 5 characters in length. 64 bit Unix operating systems can have substantially longer process IDs, which means that two Mlink processes can end up trying to use the same temporary file name during a transfer. This doesn't happen very often, but when it does, the contents of two files from separate remote locations ends up in the same file on the receiving system. The second transfer to complete reports a "Local File I/O error. #FILE = 1" error and fails the transfer.
Note that we've seen this problem occur even though the upgraded Unix kernal was built as 32 bit.
Send us an email at drmlink at mlink dot com and we'll tell you how to get the patch that fixes this problem.
Showing posts with label unix. Show all posts
Showing posts with label unix. Show all posts
Monday, February 25, 2008
Subscribe to:
Posts (Atom)