The VDF code creates new nested ZECs rooted at the old EAR ZEC. This
is the true
owner of the temp.
Yes, old .ear ZEC was reset, hence it needs to re-initialize.
Creating new nested ZEC + new temp copy is expected.
We could actually leave some thing if we knew it was a re-deploy,
but this is done per VDF bases, which is outside the VFS goal.
The scan in the middle of the deployment process gets the new EAR
ZEC,
and thus creates a new nested entry under that.
I don't see why a new EAR ZEC is created.
If we're not explicitly using VFS::createNewRoot,
then .ear's ZEC should always come off cached deploy/ root (its cached
VFSContext).
It reuses the temp that
is attached to the WAR ZEC child of the old EAR ZEC.
That's expected, to limit any new temp creation.
Dunno if that's really the best idea,
but if things are done right, I think this is definitely the optimal
solution.
As I don't see why there would have to be more then 1 temp copies.