On Fri, Mar 4, 2016 at 5:12 AM, Melvin Backus <[email protected]>
wrote:
> As I said, my guess is this has to do with indexing on the volume, but if
> that’s the case, how do I confirm that fact, and more importantly, is there
> anything I can do to fix it?
What is the security/user context that the nightly script is running
under? When you manually test; are you still testing within that context,
or your own user account?
My first inclination is also to think your problem is indexing. If thats
the case, here are some options to try:
1. Verify during your script that indexing is stopped (because it has
magical ways of restarting itself under the right conditions) by running
something like:
- NET START | FIND /I "windows search"
- IF %ERRORLEVEL% EQU 0 <DoSomething>
1. If necessary, retry with the effected directories excluded from
Indexing, or try with Windows Search permanently disabled or removed.
2. Try Robocopy instead of ForFiles and Replace. There may be an
option combination that would determine the same file modification.
Another thing to possibly check is AV software. As much as I love it - I
occasionally see MBAM choke my workstation if I make a LOT of file changes
Resource Monitor may help you eyeball some of these issues while they are
happening.
--
Espi
