Hi @karthick1356,
I think the way how you are currently using Unarchiver Process is incorrect. In my opinion zip file should be extracted on author instance, and then you should publish the result of this operation. This will give you full control in terms of activation and/or deactivation or any updates, e.g. metadata etc
The current approach you are using could produce following issues:
- you can not deactivate files that have been extracted from archive
- you can accidentally overwrite the extracted files, e.g. when you upload file with the same name in the location where zip file has been unarchived
- there could be some inconsistency between publish instance, e.g. in case when on one of the publish instance unarchive process will fail, as a result some files will be or not available for end user depending on publish instance he/she will be redirected to
- this is rather corner case, but I can imagine that for large zip archive, unarchiving process can consume lot of resources and have some temporary impact on publish instance performance
I would recommend to change location of unarchiving process to AEM author instance, this will allow to solve your problem and avoid other issues in the future.
If for any reason you still wanted to keep your process and run unarchive on publish, then you will need to transfer data related to this process (or rather results of this process) to author instance to have ability to run deactivation. This could be done using sling distribution or revers replication - but to me this sound like an overengineering.