Raar probleem met verwijderen dll-file

[gert.jansen]

Bij een van de bedrijven waar ik voor werk hebben we een gek probleem met het verwijderen van DLL bestanden.

I. Situatie:
een Windows 2000 server met een share die voor heel het bedrijf toegankelijk is - wordt via loginscript op alle clients gemapt als H:\

Op die share, een programma dat van daar gestart kan worden (moet niet geïnstalleerd). Geschreven in clarion (denk ik?), alle nodige DLLs staan in de bijhorende directory.

Alle users gebruiken dat programma tegelijkertijd en starten dat op via een shortcut naar H:\path\programma.exe.

het programma in kwestie is op maat gemaakt voor dit bedrijf en er gebeurt regelmatig onderhoud op: programmeur komt terplaatse of stuurt een nieuwe exe en/of dlls op.

II. Aanleiding:
Nieuwe update gekregen (per mail), met een nieuwe exe (voor een neventoepassing), en een nieuwe DLL file.

III. Het probleem:

1. user1 werkt met het programma
2. user2 wil de aangekregen bestanden updaten, en gooit het oude DLL bestand weg. Dit lukt (of zo lijkt het toch (*))
3. user2 wil de nieuwe DLL kopiëren. Gaat niet, krijgt foutmelding dat het bestand in gebruik is. De oude DLL staat er plots weer.
4. user2 start het programma via de snelkoppeling. Gaat niet, krijgt melding dat het DLL bestand niet kan gevonden worden.
5. Alle andere users die niet in het programma zitten en het willen opstarten krijgen dezelfde melding. De personen die al bezig waren, kunnen rustig doorwerken.
6. Wanneer user1 als laatste het programma sluit, verdwijnt ook de DLL weer, vanzelf.

(*) volgens mij is die DLL nooit echt weggeweest, zie simulering van het probleem hieronder:


IV: Simulering van dit fenomeen.
1. user1 opent het programma
2. user2 delete de DLL - hij lijkt weg
3. user2 refresht zijn windows explorer (F5) - de DLL is terug of is er nog.
4. user2 start programma: fout! DLL niet gevonden
5. user1 sluit programma: DLL verdwijnt


Zeer vervelend; ik zou hebben verwacht dat er een melding komt op het moment dat user2 probeert de DLL te verwijderen (bestand in gebruik, of zo) en dat na de foutmelding het bestand ook blijft staan. En dat hij het opnieuw moet proberen nadat alle users het programma hebben gesloten??


Wie er iemand hoe dit komt en /of wat ik eraan kan doen?

[Astralon]

Als ik het goed begrijp ligt de DLL ook in H:\path\?

Als dit zo is probeer dan eens de oude DLL te renamen, bvb mydll.dll.old
Kopieer nu de nieuwe DLL naar H:\path\

[meon]

Is het een geregistreerde DLL? Volgens mij heeft de dllcache er iets mee te maken, maar ik ken er niet genoeg van om dé reden/oplossing te weten .

[gert.jansen]

Als ik het goed begrijp ligt de DLL ook in H:\path\?

Als dit zo is probeer dan eens de oude DLL te renamen, bvb mydll.dll.old
Kopieer nu de nieuwe DLL naar H:\path\

Klopt, alle DLLs staan in H:\path.

Renamen schijnt wel te werken.

10. user1 opent programma
20. user2 renamet .dll naar .dll_
30. user2 refresht scherm -> het blijft .dll_
40. user2 start programma, gaat niet: .dll niet gevonden
50. user1 sluit programma, .dll_ blijft gewoon zo staan.

Als ik het uitbreid naar
10.
20.
30
35. user2 kopieert nieuwe versie DLL naar H:\path
40. user2 start programma -> werkt nu wel.
50. user1 & 2 sluiten programma, beide bestanden blijven staan (.dll en .dll_)

Dat werkt dus ook ...

[gert.jansen]

Is het een geregistreerde DLL? Volgens mij heeft de dllcache er iets mee te maken, maar ik ken er niet genoeg van om dé reden/oplossing te weten .

Ik denk niet dat het een geregistreerde DLL is? Het staat gewoon op een share en that's it...

Ik heb even naar de DLLcache gekeken maa rzit hij niet in.

Niet op de server - logisch, wordt enkel als fileserver gebruikt, en het programma loopt op de lokale PCs.

Niet op de client - geen enkele van die clarion dlls komt in de cache terecht.

[Rogue]

Het probleem is toch opgelost? Gewoon nog even die dll_ verwijderen en je bent rond .

[gert.jansen]

Het probleem is toch opgelost? Gewoon nog even die dll_ verwijderen en je bent rond .

Voor wat betreft het updaten van het programma en de DLLs wel.
Anderzijds, het feit dat die DLL weggesmeten kan worden (of toch virtueel - want hij verschijnt nog / is niet echt weg) irriteert me wel.

Dat is niet echt wat ik zou verwacht hebben en baart me dus wel enigszins zorgen...

[Rogue]

Het feit dat ie virtueel nog verschijnt is waarschijnlijk te danken aan gebruikers die nog de oude app draaiend hebben. Wanneer ook zij hun applicatie herstarten zal de nieuwe dll geladen worden en kan de oude definitief verwijderd worden.

Wat je kan proberen om dat te controleren is de server loskoppelen van al zijn gebruikers en dan de upgrade uitvoeren. Maar waarschijnlijk(ik weet niet hoeveel gebruikers er effectief zijn) is dat niet wenselijk in je bedrijf ivm de availability.

[gert.jansen]

Het feit dat ie virtueel nog verschijnt is waarschijnlijk te danken aan gebruikers die nog de oude app draaiend hebben. Wanneer ook zij hun applicatie herstarten zal de nieuwe dll geladen worden en kan de oude definitief verwijderd worden.

Wat je kan proberen om dat te controleren is de server loskoppelen van al zijn gebruikers en dan de upgrade uitvoeren. Maar waarschijnlijk(ik weet niet hoeveel gebruikers er effectief zijn) is dat niet wenselijk in je bedrijf ivm de availability.

Volgens mij verdwijnt hij niet echt, na een refresh na een delete is het bestand er namelijk terug (of nog - zo denk ik)

Ik zie geen enkele plaats waar dat bestand terug vandaan zou kunnen komen. Die server share is de enige plaats waar dat bestand staat.

[Rogue]

Is de applicatie ergens(bij en gebruiker?) opgestart tijdens het verwijderen van dan bestand?

[gert.jansen]

Is de applicatie ergens(bij en gebruiker?) opgestart tijdens het verwijderen van dan bestand?

Ja, zie mijn openingspost.

user1 opent het programma
user2 smijt dll van het programma weg,
etc ...

[Rogue]

Is de applicatie ergens(bij en gebruiker?) opgestart tijdens het verwijderen van dan bestand?

Ja, zie mijn openingspost.

user1 opent het programma
user2 smijt dll van het programma weg,
etc ...

dat snap ik, maar dat bedoel ik niet

probeer eens, wanneer er NIEMAND de app heeft openstaan, de dll de verwijderen & dan te kijken of ie nog terugkomt

aangezien er (hypothetisch) een gebruiker nog met de oude DLL het programma heeft opgestart, heeft hij die dll in zijn geheugen(pagefile) geladen. dit kan ervoor zorgen dat de DLL protected is...

[gert.jansen]

probeer eens, wanneer er NIEMAND de app heeft openstaan, de dll de verwijderen & dan te kijken of ie nog terugkomt

aangezien er (hypothetisch) een gebruiker nog met de oude DLL het programma heeft opgestart, heeft hij die dll in zijn geheugen(pagefile) geladen. dit kan ervoor zorgen dat de DLL protected is...

1. Verwijderen als er niemand met het programma bezig is, is geen probleem.

2. Terwijl het programma openstaat, lukt het verwijderen niet. (ttz file wordt verwijderd nadat het programma wordt afgesloten)

3. Terwijl het prgramma openstaat, de file renamen is geen enkel probleem.

De reacties bij 2. en 3. zijn niet echt consequent.

Bij een protected file zou ik net verwachten dat je melding krijgt "error: file in use" en dat het daarmee dan ophoudt. (ttz: file blijft staan)

Niet dus ...

[gert.jansen]

Het wordt nog plezanter...

Ik kan ook zonder problemen die exe zelf weggooien.
In tegenstelling tot de DLL 'verschijnt' die niet terug, maar is hij onmiddellijk weg.

Ik heb even de situatie gesimuleerd op een XP pro die ik fileserver laat spelen.

(Zie bijlage)
Het valt me op dat de bestanden geopend zijn met status 'lezen' en aantal vergrendelingen '0'. Al die bestanden kan ik vrolijk weggooien, behalve de log.tps, die in de folder 'Data' staat en geopend is met status 'schrijven'.

Daar krijg ik de melding 'file in use', en bestand blijft staan.