During a recent Production implementation of BizTalk 2009 we ran into an issue with the temporary folder option in the NSoftware FTP adapter. The error itself is not an NSoftware bug, but rather a feature/limitation of the FTP Protocol.
Event Type: Error
Event Source: nsoftware BizTalk FTP Transmit Adapter
Event Category: None
Event ID: 0
Time: 2:50:22 PM
Source: nsoftware BizTalk FTP Transmit Adapter (3.5.3488.0)
Source URI: FTP://%User%@%FTPServer%:21/%RemotePath%/%RemoteFile%
Message Type: Error
Current Thread: 71
Transmission failed for message "019ef16e-0b57-4309-8a37-b5c05a61e7f9": Error uploading FTP data: FTP protocol error: 550 rename: Cross-device link
If this error persists, you may enable Warning or Verbose logging modes to enable the adapter to report more information regarding the progression of this error.
Our scenario involved writing files in a specific sequence using delivery notification and using a temporary folder to support some reliability requirements. The idea behind using a temp folder is you get the data to a “staging” area and once the adapter can confirm that all data was written it performs a rename operation on that file which is extremely quick. It also reduces the risk of a consuming application retrieving the data from the file as it is being written. This is especially important in *nix environments since file level locking has not been implemented the same way as it has in Windows environments.
Here is how our destination folders have been configured:
Since we are using delivery notification, the “work” file has to be written to first. Once that operation has completed, then the arch(archive) file can be written. Both of these messages are being sent through a dynamic send port and we have a routing rules repository where we store the specifics of where the message is suppose to be delivered to. Our configuration called for both operations to use the same temp location. (Hindsight is 20/20)
In Test, everything worked out perfectly but when we ran this process in Prod we ended up with the aforementioned error. The difference between these environments is that the “arch” folder exists on a separate disk than “work” or “temp” in Prod. Essentially the FTP Protocol cannot perform the rename operation from the “temp” folder across to a folder on a different disk that has been mounted to the same server.
I was able to validate this by opening up a command prompt and establishing an FTP session. Once I connected I tried to rename a file and place it on the “arch” disk. I got a similar error:
ftp> rename list.txt /home/arch
350 File exists, ready for destination name
550 rename: Cross-device link
In a previous blog post I discussed that NSoftware use to have a property called temporary file extension. This property is no longer a property that is exposed in the Send Port configuration but is still supported when you dive into their documentation. To use this property , you want to click on the “…” button beside the “Other” property.
In this property dialog box, populate TemporaryUploadExtension=.tmp
This feature acts similarly to the temp folder, the difference is that the “temp” file will be written to the same folder as the file that you are transferring . A consuming system that respects file extensions will still be “OK” with this situation since the file name will have “.tmp” added to it until the entire file has been written and at this point will remove this temporary extension via the rename operation.
This situation just highlights how important matching your QA/Test environments and Production really is. The other lesson is that not everything is exactly as it appears. In our case the folder structures were exactly the same. The difference was that one of the folders was mounted to a different disk. Finding this out is not a lot of fun when you are in the middle of a go live.