Problem

-- After purging the Gateway mailbox, the Local ID of the transfers take random values, and do not continue incrementing from the last ID number.
-- Example :
You can see in the log.dat file that the local ID jumps from 2841 to 224

Gateway allocates transfer IDs as follows:

* It tries to allocate the next available local id, so following 2841 it will try to allocate 2842
* If a transfer with 2842 already exists, it will apply the algorithm to check for an available ID
* It starts looking for available slots from from 0.
Example : If transfers with IDs 1-223 exist in the mailbox, it finds the first slot of available IDs to begin with 224.

If purges are done but the associated transfer files still exist, then eventually this algorithm can lead to filename conflicts. With most protocols this will cause the transfer files to be overwritten, but with some (such as PeSIT) this will lead to the transfer being refused with the error "File already exists." The way to avoid this is to make sure all purge jobs also remove the associated transfer files (-pf option). If you don't want the transfer IDs to skip around as described above, also make sure that your purge jobs don't leave gaps (for example, purging some transfers after 5 days and others after 7, or purging some transfer states and not others).

Also note that this reuse of transfer IDs can cause Sentinel CycleIDs to be duplicated, since one piece of data that goes into generating the CycleID is the transfer ID. For this purpose, too, it is important, as above, to ensure that your transfers are purged in order, such that the transfer IDs don't get reused.