[ASP.NET - C#] directory delete: onverklaarbaar prob.

[Verwijderd]

Het enige dat ik wil is recursief een directory verwijderen... dus ik netjes Directory.Delete(path, true), werkt lokaal als een trein. Toen ik het online bij de klant neerzette ging ie ineens 'at random' met onderstaande exceptionspecs komen: "The directory is not empty." Terwijl k gewoon recursive had aangegeven als parameter..

Toen dacht ik het misschien te kunnen oplossen door zelf in de directories naar beneden te fietsen en dan alle files een voor een deleten alvorens de (op dat moment dus lege) directories te deleten. Maar ook in dit geval krijg ik weer dezelfde exception om mn oren.

Ik ben al de hele f****n avond en nacht bezig met zoeken maar kan op google, microsoft, vele fora helemaal niets hierover vinden. Tuurlijk vindt ik zal artikeltjes over het verwijderen van een directory, dat zou ook geen zak voor moeten stellen. Maar het levert dus toch veel problemen op.. K heb geen flauw idee wat het nog zou kunnen zijn, iemand hier die me verder kan helpen?..

situatie
Ik heb een backup systeem, deze zet de backup in een directory a. Zodra de gebruiker deze backup wil restoren wordt er eerst nog een backup gemaakt van de huidige situatie (mocht de restore van backup a mislukken) en deze wordt opgeslagen als backup b. Zodra de restore van backup a gelukt is wordt backup b automatisch weer verwijderd. Althans, dat zou zo moeten zijn.. maar .NET wil dat dus 9 van de 10 keer niet doen.. en komt met die "not empty" exception..

Het vreemde is dus dat het niet 10 van de 10 keer gebeurt maar iets van 7-8 van de 10 keer.. er valt dus geen pijl op te trekken...

specs
Lokaal zit ik achter windows xp, IIS 5, ASP.NET 1.1 en online staat een windows 2003 server, IIS 6, ASP.NET 1.1.

[Glimi]

Backups worden meestal preservive gemaakt, maw de userdata blijft behouden. Het kan best zijn dat jij geen rechten hebt om de data te verwijderen. Het is dan wel raar als het een full-backup is over telkens dezelfde dataset. Kijk anders even welke bestanden overblijven in de directory met welke rechten.

[GrimaceODespair]

Heeeeeeey! Je beschrijft exact mijn probleem! Ik heb een NAnt build script dat websites kan publiceren. Daarvoor moet het eerst de site stoppen, het AppDomain unloaden (ff web.config touchen) en de directories verwijderen.

Bij mij gebeurt het dus ook at random dat ie niet slaagt in het verwijderen van directories. Ik had al timeouts gezet tussen stoppen van de site, touchen van de web.config en verwijderen van de dirs, to no relief.

Wat ik nog niet geprobeerd heb, is die sub-directories doorfietsen, en tussen elke delete een delay inbouwen. Als dat al zou werken, zou het natuurlijk wel tijdrovend worden.

Hmm... en terwijl ik dit schrijf, krijg ik ineens het idee om de indexing service voor die dirs uit te schakelen. Mss kan je daar eens op controleren bij de klant, en kijken of het werkt, als het uitgeshakeld is.

Verder is het mss nuttig om op te merken dat er ook wel eens erg vage dingen plegen te gebeuren als er een virusscanner langs komt. Deze kan namelijk heel even bestanden locken vlak nadat ze geschreven zijn (of vlak voordat ze verwijderd worden?), zodat je geen toegang hebt tot een pasgemaakt bestand. Dit is een bug die de makers van Subversion op het Windows-platform al flinke hoofdbrekers heeft bezorgd.

edit:
Misschien overbodig om op te merken, maar NAnt is dus in .NET geschreven

[ Voor 4% gewijzigd door GrimaceODespair op 25-10-2004 08:54 ]

[Janoz]

Het zou best kunnen dat er nog enkele bestanden in gebruik zijn. Windows kan deze bestanden dan niet verwijderen en de directory is in dat geval dus niet leeg. Dat is een 'feature' van FAT en NTFS. Misschien werkt het wel waneer je de volledige applicatie eerst compleet stopt en unload oid.

Hetzelfde probleem hebben wij ook met onze windows j2ee applicatie server. Als we een nieuwe lib neer willen zetten moetsten we alle 150 applicaties stoppen voordat we het bestand konden kopieren.

[mulder]

Volgens mij wil dit ook wel eens gebeuren als je dingen in de Explorer verwijdert, dit is een Windows probleem. Waarschijnlijk als nog een keer probeert te verwijderen, of even wacht met het verwijderen van de hoofdmap dan gaat het goed.

[Verwijderd]

Don, wat jij zegt klopt idd.. de ene keer gaat het wel goed, en de andere keer niet.. en dan gaat ie bijv. fout en meteen daarna wel goed... heel weird..

Maar als een file in gebruik is dan gooit ie toch een andere exception? Op precies te zijn, een UnauthorizedAccessException..
(http://msdn.microsoft.com...ctoryclassdeletetopic.asp)

Kan het inderdaad zijn dat ie IOException 'not empty' gooit als er een file in use is?..


p.s. bugje in react?.. -> zie url hierboven

[ Voor 11% gewijzigd door Verwijderd op 27-10-2004 12:41 ]

[GrimaceODespair]

Verwijderd schreef op 27 oktober 2004 @ 12:40:
Maar als een file in gebruik is dan gooit ie toch een andere exception? Op precies te zijn, een UnauthorizedAccessException
(http://msdn.microsoft.com...ctoryclassdeletetopic.asp)

Kan het inderdaad zijn dat ie IOException 'not empty' gooit als er een file in use is?..

Een file kan op 2 manieren in gebruik zijn:

1. Een programma heeft het bestand op een 'normale' manier in gebruik.
2. Een monitor (virusscanner, indexing service, ...) die het bestand even lockt nadat het aangemaakt/veranderd is.

Volgens mij hangt de melding af van de manier waarop het bestand gelockt is.

[Janoz]

offtopic:
Mwah, het - teken wordt niet als url zelf herkend. Het herkennen van URL's is sowieso een extra feature. Wil je dat deze daadwerkelijk altijd goed gaat, gebruik dan de [url] tag. Mooi voorbeeld in deze is dat de url nog steeds niet goed gaat waneer hij het streepje wel had gepakt, aangezien hij dan weer over zijn nek zou kunnen gaan van de ) achteraan. Zo werkt ie wel : [url]http://msdn.microsoft.com...fault.asp?url=/library/en-us/cpref/html/frlrfsystemiodirectoryclassdeletetopic.asp[/url]

[P_de_B]

offtopic:
[rml][ BUG] links worden afgekapt na '-'[/rml]

[Verwijderd]

hm.. k ga maar ns aan de slag om te kijken wat die files evt. zou kunnen locken/in use zetten...

thanks tot nu toe! als ik meer tegen kom horen jullie het wel!

[ Voor 27% gewijzigd door Verwijderd op 28-10-2004 00:51 ]

[Verwijderd]

Ik heb een soortgelijk probleem in het verleden opgelost door de files die ik niet kon verwijderen in een database-je te bewaren en het later nog eens te proberen. Als ik toen op de server keek wie de filelocks had, was het in mijn geval altijd IIS.

[Verwijderd]

Verwijderd schreef op 28 oktober 2004 @ 11:59:
Ik heb een soortgelijk probleem in het verleden opgelost door de files die ik niet kon verwijderen in een database-je te bewaren en het later nog eens te proberen. Als ik toen op de server keek wie de filelocks had, was het in mijn geval altijd IIS.

kee, thanks.. ik zal dat ook mee nemen in mn zoektocht!!

[GrimaceODespair]

Overigens, onontbeerlijk is ook WhoLockMe. Is een van de eerste apps die ik op nieuwe machines installeer.

Maar let erop dat, zelfs al bespeurt de app geen bestanden die in gebruik zijn, je soms bestanden toch niet kunt verwijderen. Dat gebeurt volgens mij oa als je locking wijze nummer 2 aan de hand. Maar dat laatste is slecht speculatie.

[ Voor 50% gewijzigd door GrimaceODespair op 29-10-2004 08:11 ]

[Verwijderd]

GrimaceODespair schreef op 29 oktober 2004 @ 08:07:
Overigens, onontbeerlijk is ook WhoLockMe. Is een van de eerste apps die ik op nieuwe machines installeer.

Maar let erop dat, zelfs al bespeurt de app geen bestanden die in gebruik zijn, je soms bestanden toch niet kunt verwijderen. Dat gebeurt volgens mij oa als je locking wijze nummer 2 aan de hand. Maar dat laatste is slecht speculatie.

kee, thanks voor de tip! ik ga die tool ook ff proberen..

korte update: op dit moment hebben we in de virusscanner de specifieke directory ge-exclude en indexing service uit gezet... nu gaan we testen of het nu wel werkt en het dus aan deze twee heeft gelegen...