Dit overkomt mij veel met mijn geautomatiseerde build scripts.
De reden zou kunnen zijn dat er een applicatie is die een bestand open heeft staan in die directory met “share delete”. D.w.z. de applicatie staat een verwijdering van het bestand toe (daarom denk ik dat de DeleteFile call niet mislukt), maar het bestand zal pas verdwijnen nadat de applicatie zijn handvat heeft gesloten.
Dat betekent dat het bestand er misschien nog steeds is als het rmdir
commando de map probeert te verwijderen, vandaar de foutmelding. Kort daarna zal de genoemde applicatie het handvat sluiten, het bestand zal verdwijnen, en als je de map inspecteert om te zien welk bestand rmdir
er over sprak zal het leeg zijn.
Dat is tenminste mijn theorie.
De door Harry Johnston voorgestelde workaround ziet er goed uit. Alleen zou ik een pauze inlassen tussen de rmdir
commando’s. Natuurlijk heeft Windows geen gemakkelijk te scripten “pauze” commando (correctie: oude Windows versies niet, nieuwere hebben - zie commentaar). Maar als seconden granulariteit genoeg is kan men ping
gebruiken om een pauze te maken:
ping -n {desired_delay_in_seconds + 1} 127.0.0.1 >nul
Dus in totaal:
rd /s /q foo
:: retry once
if exist foo (
:: clear errorlevel
cmd /c
:: pause
ping -n 2 127.0.0.1 >nul
:: retry
rd /s /q foo
)
:: retry yet again
if exist foo (
cmd /c
ping -n 2 127.0.0.1 >nul
rd /s /q foo
)
:: give up
if exist foo {panic}