While I can't dismiss the possibility of file indexers and virus 
scanners, in my experience most problems are closer to home ;-) It 
should also be easy to find out by running the code on a box without 
much crapware installed.

Cheers,
   - Andreas

Martin v. Löwis wrote:
>> - we extract a zip archive to provide an initial setup for Plopp data
>> - then the user can play around in demo mode (problem doesn't occur in a
>> full version as the deletion doesn't take place)
>> - upon quitting demo mode all data is erased via a recursive directory
>> delete
>>
>>
>> We have simple test up without running the UI to reproduce the problem.
>>
>> The delete fails about 1 in 10 with a primitive failed in deleteDirectory.
>>
>> There are no open files or anything obvious.
> 
> That's a fairly common problem with file deletion on Windows. On a
> typical installation, there *are* often open files - the usual
> suspects are a virus scanners and file system indexers/search engines;
> the explorer may also open files if the directory is display in the
> explorer.
> They register for file change notifications, and when files are created,
> they put them onto their todo list, and will eventually open them
> (usually fairly quickly after they got created). They then read them
> once, and deletion attempts will fail at that point.
> 
> If that's the cause, it is fairly difficult to work-around. The "proper"
> way is first to try DeleteFile (talking plain Win32 API here); if that
> fails with sharing violation, move the file to the trash folder, open
> it for deletion, SetFileInformation with a delete disposition, and close
> the file. In the latter case, the file will go away if the last handle
> is closed.
> 
> If you wait some time and retry, whoever had the file open will have
> closed it.
> 
> Regards,
> Martin
> 
> 
>