[W2k] Bestanden niet te deleten

[Compacto]

Een vriend van me heeft twee servers staan. 1 als normale data server en nog een tweede als back-up. Om de zoveel dagen wordt er door middel van een dos-batch script de gehele back-up server gewist en wordt de data van de gewone server opnieuw naar de back-up server gekopieerd.
Dit gehele proces werkte eerst prima, maar sinds kort gaat het niet meer helemaal goed. Bij het wissen van de bestanden op de server wordt er bij enkele tientallen bestanden de melding gegevens "het bestand is in gebruik en kan niet verwijderd worden". Ik heb gekeken welke programma's of processen de bestanden gebruiken. Ik kan echter niets vinden, ook de virusscanner bleek het niet te zijn.

Nu zoek ik een programma wat kan weergeven welk proces of programma de bestanden geopend heeft, zodat ik dat programma dan kan sluiten.

Opmerking: Het betreft een Windows 2000 opgeving. Ik ben echter niet ter plaatste en kan dus niet testen. Het is ook niet de bedoeling om de server opnieuw op te moeten starten (bijvoorbeeld in veilige modus) bij iedere keer dat de bestanden gedelete worden.

[Verwijderd]

Er zijn een paar opties eigenlijk, maar hidden/ro files lijken me de meest waarschijnlijke.

[F_J_K]

Wat voor soort bestanden zijn het? Als het om bijv. avi gaat, kan je even de tip in de WOS FAQ proberen.

[sh4d0wman]

hier hebben we onder 2K servers nog wel eens dat bestanden in gebruik blijven terwijl er niemand in werkt. ze zijn ook nergens terug te vinden. tot nu toe hielp het alleen om te rebooten.....

we hebben SP3 btw

edit: de reactie onder mij kan idd wel werken (hier is het nog steeds een probleem omdat de bestanden niet weg moeten maar gewoon bewerkt moeten worden)

[ Voor 27% gewijzigd door sh4d0wman op 21-01-2003 12:48 ]

[Bergen]

Had ik laatst ook last van, het waren enkele bestanden met erg lange namen. Kon ze ook met geen mogelijkheid weg krijgen terwijl ze door geen enkel proces in gebruik waren.

De oplossing was simpel: deleten vanuit een dosprompt. No problem. Gewoon del * in de map.

[Verwijderd]

GerbenW schreef op 21 January 2003 @ 12:46:
Had ik laatst ook last van, het waren enkele bestanden met erg lange namen. Kon ze ook met geen mogelijkheid weg krijgen terwijl ze door geen enkel proces in gebruik waren.

De oplossing was simpel: deleten vanuit een dosprompt. No problem. Gewoon del * in de map.

hij draait een dos-script, dus dit zal hem niet helpen.

Heeft dit niet te maken met read-only attributes, of NTFS rechten?
En verhelpt een reboot het probleem?

[elevator]

kijk hier eens naar:
http://www.microsoft.com/...t/tools/existing/oh-o.asp

==

[google=open handles]

[Compacto]

OK, even mijn reactie op alle replies (bedankt voor de reacties trouwens):

1) Het zijn geen read-only of hidden bestanden
2) Er zitten inderdaad mogelijk langere bestandsnamen tussen
3) Rebooten haalt het probleem niet weg. Echter als ik het script nogmaals draait haalt hij wel weer wat meer bestanden weg.. echter dan moet ik het script meerdere keren draaien voordat alles weg is.

Het liefst zal ik eerst eens willen kijken welk programma/proces de bestanden gebruikt, dan is het probleem bij de oorzaak op te lossen, ipv er omheen te werken. Weet iemand hoe ik dat kan doen ?

[Edit] Ik geloof dat er net iemand met een mogelijke oplossing(Open handles) kwam toen ik het bovenstaande aan het typen was.. ik ga het proberen

[ Voor 12% gewijzigd door Compacto op 21-01-2003 14:06 ]

[Verwijderd]

Aha! Draai je het script over de netwerkverbinding naar de andere server?

[endeavor334]

Bij mij had ik het ook, windows kon hem diet deleten ook niet na een reboot. Oplossing dat bij mij werkt was opstarten in veilige modus en dan deleten.

[Compacto]

Verwijderd schreef op 21 January 2003 @ 14:11:
Aha! Draai je het script over de netwerkverbinding naar de andere server?

Klopt, de schijven van beiden servers worden geshared. Het script worden vervolgens gedraait vanaf een derde computer.

[gatlarf]

Move on boot kan bestanden in use bij de volgende reboot verwijderen/moven
http://www.gibinsoft.net/gipoutils/fileutil/index.htm

Hopelijk heb je hier iets aan