[RTFACT-7460] Prevent replication of metadata temp (_tmp, _temp) folders from the source Artifactory to the destination server Created: 11/May/15  Updated: 04/Feb/20  Resolved: 21/May/19

Status: Reopened
Project: Artifactory Binary Repository
Component/s: Replication, RPM, YUM
Affects Version/s: 4.0.0
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: Alexei Vainshtein Assignee: Shay Bagants
Resolution: Fixed Votes: 3
Labels: None

Attachments: Text File destination.log     Text File orign.log    
Issue Links:
Relationship
relates to RTFACT-8886 Exclude metadata files on push / pull... Resolved
is related to RTFACT-7410 Yum metadata auto-calculation with ev... Open
is related to RTFACT-15407 The temporary Docker _uploads folder ... Resolved
Sprint: Leap 37

 Description   

If the replication is triggered when the calculation of metadata on YUM/Debian repository is running then the indexes temporary folders ( _tmp for YUM, _temp for Debian) are being replicated also.

Steps to reproduce:

1. Create a replication with event base replication enabled on a YUM repository.
2. Run calculation on the repository.
3. While the calculation is running, deploy a new artifact to the YUM repository. Now the replication will be triggered and the _tmp folders will be replicated also.

Workaround for this issue:

1. Check the checkbox for Sync Deletes in the replication tab. This will delete all the folders in the destination Artifactory that were removed in the source Artifactory also. Please note, that this will remove artifacts that were deleted also.
2. Use the plugin for clean-up an empty folders from our public GitHub repository: https://github.com/JFrogDev/artifactory-user-plugins/blob/master/cleanup/deleteEmptyDirs.groovy



 Comments   
Comment by Kyle Leinen [ 18/May/16 ]

Our Artifactory ecosystem has 9 large yum repos that are replicated to 4 regional servers. This _tmp_ replication issue is causing lots of thrashing and unnecessary network and CPU load. It would be nice if there was an exclude setting in the replication that would be able to filter this out, or if the replication process would just identify Artifactory's own temp files and not replicate those. (or get the yum indexer to not generate those files in that place)

We are using Artifactory Enterprise 4.7.1

Generated at Sun Feb 23 14:24:45 UTC 2020 using JIRA 7.6.16#76018-sha1:9ed376192612a49536ac834c64177a0fed6290f5.