Package Indexing Error

Hi Guys
today we update proget to the new version 3.1.3 and after the update process the service starts the reindexing and we get this error.

Package Indexing Error
Feed ES_deploy
Package Test.0.11.0-alpha-546.nupkg
Message The process cannot access the file 'D:\Data\Test\Test.0.11.0-alpha-546.nupkg' because it is being used by another process.
Date 9/15/2014 9:21:00 AM
Stack Trace at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
at Inedo.NuGet.Packages.NuGetPackage.ReadFromNupkgFile(String fileName)
at Inedo.ProGet.Extensibility.PackageStores.DirectoryPackageStore.TryReadPackage(String fileName)

Pls tell us how we can stop the reindex and add a flag or command or something else that the service don't start the index after every restart.

The reindexing process need 4houre by us and in this time proget can't be used

Product: ProGet
Version: 3.1.3

The index can only get completely rebuilt if the RebuildPackageIndex option in Admin->All Settings is set to true.

Can you verify that this is false?

Yes this setting is false.

The reindexing process runs each time the Serivce is restarted

We were planning to remove the filewatcher entirely in a future version. For now, we have added a UseFileSystemWatcher setting on the Admin->All Settings page. If you set this to False, and then restart the ProGet service, it will not use the watcher at all. Instead, it will check for updated files at the interval in the FeedIndexerThrottle setting (which by default is 60 seconds).

Our best guess is that the internal buffer on the filewatcher was overflowing due to the large number of files, causing this strange behavior. Let us know if this helps. v3.1.5 with this workaround has been released.