I have a Zenapp that only copys down files - nothing else. It copys down
about 20MB. This app is workstation associated, runs only when the user is
not signed on, and is *not* set to "track distribution per user." It is
set to cache and is disconnectable. It is set to force run and run once.
It runs in the secured system context. It is not on a schedule.

With one exception, all the files are specified to copy only if newer. One
is set to copy if different, which is 706KB.

I made a change to this Zenapp. One of the files, 120KB, was updated. So
I put the new file into the source directory and incremented the zenapp
version number.

It distributed locally fine, but utilization on my remote links went to
100% for up to 9 hours to distribute this 120KB file. That seems very
odd. It shouldn't have been but a blip on the MRTG charts.

I connected to one of the remote machines. It attempted to update this one
file, but failed. Resulting in the previously existing NALCACHE directory
to be removed. That means the next time this app tries to download, it's
got to download the entire app into cache again, right?

Logging shows it cached correctly, however it isn't in nalcache like it is
on other stations;

"Cache Success","60","1/27/2006 6:56:59
DOWNLOAD.INOCULAN7.APPLICATIONS.EPRIME_BASE.EPRIME ","88290BC5-4D16-4951-B8FE-09549D73D360","3","0","0","C:\NALCache","","",""," ","2070912"

(No other events after this - no distribution success.)

Why would it say Cache Success, but not have the .NEW INOC7* directory?
Why did it take 9 hours to distribute this app across the WAN, when it's
just a 120k file? Did Zen COPY ALL the files into NALCACHE again, then
only apply the "Copy if newer" between NalCache and the destination? Does
this mean I should disable caching?

I'm doing something wrong - I just don't know what.