I have an automated script that calls a VB dll which makes some calls to
Scripting.FileSystemObject for moving a lot of files around in various ways.
This is used as part of our build automation which archives folders from each
build. After about a week, the files for some expired archives are removed.
This has been working for about a year without any trouble. Recently, The
delete of the folders in the archive is failing with an Access Denied error
(Err.Number = 70). After much investigation, by using process explorer (from
sysinternals.com) I was able to determine the culprit locking the
directories. The System process (PID = 8) has a handle open to the
directories in question. These directories are located under a shared
directory so I checked to see if any connected users have the folder/files
open - nobody is connected. The handle seems to have been opened at the time
the files were copied into the archive directory and never closed. I have
attempted the following to see if it releases this handle.
- closed all applications and explorer windows
- stopped IIS services (W3SVC, IISADMIN, MSFTPSVC, SMTPSVC)
- stopped content indexing service (set to manual and does not run anyway)
- stopped anti-virus services (McAffee)
- checked the shared folders/open files from Computer Management
- restarted the lanmanserver service (including dependent services - DFS and
Computer browser)
The final step actually released the handles. Is this a bug? Could it be a
side-effect of a recent security update - probably in December?