You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes when the dotNetInstaller setup bootstrapper terminates, an error message similar to the following is displayed:
[Setup Title]
0x80070091 - Error deleting directory: C:\Users\UserName\AppData\Local\Temp\{5D6ADB09-8C3A-4E67-A987-E4200838CF54}: The directory is not empty.
[OK]
The dotNetInstallerLog.txt indicates messages similar to the following:
2015-06-03 15:19:49 All required components installed: yes
2015-06-03 15:19:49 All optional components installed: yes
2015-06-03 15:19:49 All checked components installed: yes
2015-06-03 15:19:49 --- Complete Command
2015-06-03 15:19:49 Deleting CAB folder: C:\Users\UserName\AppData\Local\Temp\{5D6ADB09-8C3A-4E67-A987-E4200838CF54}
2015-06-03 15:19:49 Error terminating dotNetInstaller: 0x80070091 - Error deleting directory: C:\Users\UserName\AppData\Local\Temp\{5D6ADB09-8C3A-4E67-A987-E4200838CF54}: The directory is not empty.
I have verified that the directory is empty and it can be deleted manually.
I expect the dotNetInstaller setup bootstrapper to retry deleting the directory after a little delay in case there's an open handle to the directory that hasn't quite closed yet.
The text was updated successfully, but these errors were encountered:
I don't think the problem is an unclosed handle. There's something in that directory while DNI is terminating, possibly a running setup or something like that. Retrying seems optimistic, you should be able to resolve this fully, just track down what that something is?
I'm sure it could happen with other anti-virus solutions.
Here is a thread from a different project reporting a similar issue caused by ESET Anti-Virus for example: isaacs/rimraf#25 (comment)
I can't seem to enable verbose logging in Windows Defender to see if it outputs any information about scanning the directory around the time we are trying to delete it.
Any ideas?
Should I just reapply the retry logic, or is there a better solution?
For example, should the retry logic behavior and its parameters be exposed as optional attributes in the dotNetInstaller xml configuration file?
For example, retry_delete_directory="false" retry_delete_directory_maximum_retries="10" retry_delete_directory_wait_between_retries="100'
Or maybe the message box that is displayed should have Retry and Continue buttons?
I would be down for a feature that retries a maximum amount of times with settings. I would hard-code a second wait time or something instead of giving people the opportunity to put endlessly long times in there.
Sometimes when the dotNetInstaller setup bootstrapper terminates, an error message similar to the following is displayed:
The dotNetInstallerLog.txt indicates messages similar to the following:
I have verified that the directory is empty and it can be deleted manually.
I expect the dotNetInstaller setup bootstrapper to retry deleting the directory after a little delay in case there's an open handle to the directory that hasn't quite closed yet.
The text was updated successfully, but these errors were encountered: