In most cases, this should not happen. For example, when the package is in transfer during a mirror operation, if there is an interruption, the mirror process should resume and the file should be moved out of the InTransfer folder. If, for some reason, the payload is orphaned by removal of the payload on the master distribution point in an irregular manner (removal of the binary without first removing the payload entry from the Server Center), I could see the payload remaining on the mirror DP in transfer indefinitely.
How I would approach this would be to check the payload UIDs in the filesystem of the InTransfer folder and validate that they do not exist on the Master DP. My guess is that they do not and that they have been orphaned. If this is the case, and there is no database record (payload UID does not appear in Server Center), then you are safe to remove these files from your InTransfer folder.
So Would it be possible, if I deleted an Windows or 3rd party patch from the Manage Admin GUI and the payload was in the replication state in the LANrev InTransfer directory of DP before it completed replication it would be orphaned?
Thats a good question. I think that could happen, but if it should happen is another question. The proper behaviour would be that if a package is deleted from the UI, and if it is currently being mirrored, that the file would be cleaned up automatically with no involvement by the end user. If that is not happening, I will create an engineering ticket to modify the behaviour. This will need some additional testing on my part, and I will do so and log an engineering ticket if required.
I think that might be the case I have a # of DP’s with a large amount of files with old time stamps in the LANrev InTransfer.
After doing a spot check on few of the payload ids most are patches or 3rd party patches I deleted from the Manage Admin Gui Console.
I also saw this article and wonder if this might be the cause on the some of the packages in LANRev InTransfer directory.
Your thoughts ?
I was thinking updating the SDPackagePayloadTransferTime to 86400 or 24 hours. Your thoughts ?
I don't think the transfer is the problem, as the package does get uploaded to the master DP. I tried to reproduce the issue by doing the following:
1) add a large payload to the Software Packages list (4GB)
2) Confirm package uploads to master
3) observe mirror process and confirm file hitting the InTransfer folder on the secondary mirror
4) Delete the package via admin console and commit changes
The result is that the compressed, encrypted payload that is in the InTransfer folder gets cleaned up correctly (mid download). So, I think the problem is that you are having orphan records of the payload UIDs within the db itself. Thus, deleting the records from the admin console is not actually triggering a removal of the actual binary payload on the master and consequently the file gets orphaned on all DPs.
We are currently looking into this further on the engineering side and we have an open support case for the issue that we will continue this topic on.