Upgrading Unix OS Mlink problem

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.

Welcome to the Mlink Guru blog

Hello, this is Dr. Mlink, owner and President of Mlink.com LLC - welcome to the Mlink user's blog. I hope to make this a place where Mlink and ACM users can converse about data transport issues, polling system design, modems, networks, security and anything else we can help you with.

Mlink and ACM are legacy products, yet they are still in use by mom 'n pop shops as well as Fortune 500 corporations worldwide. Mlink is still actively sold and new clients are being added all the time.

I welcome your questions and comments - Mlink and ACM have needed a user's group for quite some time!