C# Ionic.Zip:Sperrung / Entsperrung der Dateien?

[Alex.Konnen]

Ich entwickle einen Zusatzmodul für eine vorhandenene C # (4.0) Anwendung, die zur Datenspeicherung Ionic Zip-Bibliothek verwendet.
In meinem Modul muss ich Daten von Zip-Dateien laden, manipulieren, und zurück schreiben. Meine Routine läuft OK in Unit-Tests, aber wenn sie aus der Host-Anwendung aufgerufen wird,
bekomme ich eine Exception des folgenden Inhalts: "Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird".
Dies geschieht zu einem Programmpunkt, wo ich versuche, die Save()-Funktion des Zip-Archiv aufzurufen.

Ich habe überprüft, welcher Prozess die Datei tatsächlich sperrt, und es sieht so aus, dass dies die Anwendung selbst ist.
Daraus schließe ich, dass es vielleicht eine Art von Interferenz mit dem Host-Programm gibt: zB wird ein File Stream geöffnet, aber nie geschlossen. (BTW, gibt es einige intelligente Techniken, um nach solchen Stellen zu suchen?)

Was mich generell wundert ist, ob ZipFile von Ionic Dateien tatsächlich sperrt/entsperrt, wie im folgenden Codestück:

ZipFile zf  = new ZipFile("test01.zip");
zf.Save();

// FileSystemTools.WhoIsLocking is a utility showing a list pf processes
// holding access to a given file
// Similar to http://stackoverflow.com/questions/1304/how-to-check-for-file-lock/20623302#20623302

List<Process> processes = FileSystemTools.WhoIsLocking("test01.zip");
Assert.That(processes.Count == 1);

zf.Dispose();
processes   = FileSystemTools.WhoIsLocking("test01.zip");
Assert.That(processes.Count == 0);

Nach Save() ist die Anzahl der sperrenden Prozesse gleich 1 (der laufende Prozess selbst), aber nach Dispose() gibt es keine,
was einen auf den Gedanken bringt, dass Ionic.ZipFile offensichtlich einige File Streams intern verwaltet.

An anderen Stellen hat Dispose() jedoch keine Wirkung: Die Zahl der Sperrungen wird nicht dekrementiert.

Danke für Meinungen, Ideen und Tipps,
Alex

[Ralf Jansen]

Der Code sieht vermutlich nur zur Darstellung als Beispiel so aus, richtig? Im eigentlichen Code fehlt kein try..finally oder using für ZipFile.Dispose() ?

Was mich generell wundert ist, ob ZipFile von Ionic Dateien tatsächlich sperrt/entsperrt,

Sourcecode der Komponente anschauen? Vielleicht gibt die Implementierung von Dispose ja tatsächlich Hinweise zu Lücken bezüglich des freigeben des Files.

Ich habe überprüft, welcher Prozess die Datei tatsächlich sperrt, und es sieht so aus, dass dies die Anwendung selbst ist.

Sicher das du es selbst bist? Wenn man Prozesse schreibt die ein File mehrmals touchen kommt einem oft genug AV Software dazwischen

[Alex.Konnen]

Hallo Ralf,
danke für die rasche Antwort.

Der Code sieht vermutlich nur zur Darstellung als Beispiel so aus, richtig? Im eigentlichen Code fehlt kein try..finally oder using für ZipFile.Dispose() ?


Ja, das ist ein kurzer Test zu Thema was passiert wenn ZipFile speichert und dispost. In meinem Quellcode habe ich durchgehend new ZipFile(...) + Dispose() benutzt. Werde auch versuchen, alles durch "using" zu ersetzen, habe aber wenig Hoffnung, dass es etwas ändert, da in meinen UnitTests sind (noch) keine Unterschiede zwischen den beiden Varianten aufgetreten. Naive Frage: gibt es eine Methode, eine Datei per Brute Force zu unlocken?


Sourcecode der Komponente anschauen? Vielleicht gibt die Implementierung von Dispose ja tatsächlich Hinweise zu Lücken bezüglich des freigeben des Files.


Hätte ich meine Schwierigkeiten, den entsprechenden (meinen) Code in überschaubaren Abschnitten darzustellen... Ich werde es eventuell aber versuchen und dann melde ich mich damit.


Sicher das du es selbst bist? Wenn man Prozesse schreibt die ein File mehrmals touchen kommt einem oft genug AV Software dazwischen


Das Tool, das ich verwende wie auch zB handle.exe zeigen auf den Prozess in dem ich aktuell laufe. Es sieht nicht wie AV aus, denn ich habe Duzente von Malen ausprobiert, auch mit langem Warten, es kommt immer.

[Ralf Jansen]

Konnte in dem vermutlich relevanten Codepfad in ZipFile (von https://dotnetzip.codeplex.com/) nichts sehen das irgendwie systemabhängig wäre.

Kannst du deine Unittests so umbauen das sie ihre Test mehrmals wiederholen? Also nicht den Test mehrmals starten dann gibt es bestimmt zwingend mal eine Aufräumen durch den gc sondern so das eben kein irgendwie geartetes Aufräumen durch den GC oder Ionic intern auftritt? Bei Unittest mit ihrem atomaren Ansatz gehen Probleme mit dem Resourcenhandling ja gern schonmal durch.

[Alex.Konnen]

[QUOTE=Ralf Jansen;282519]

Konnte in dem vermutlich relevanten Codepfad in ZipFile (von https://dotnetzip.codeplex.com/) nichts sehen das irgendwie systemabhängig wäre.
Kannst du deine Unittests so umbauen das sie ihre Test mehrmals wiederholen?
Also nicht den Test mehrmals starten dann gibt es bestimmt zwingend mal eine Aufräumen durch den gc sondern so das eben kein irgendwie geartetes Aufräumen durch den GC oder Ionic intern auftritt?
Bei Unittest mit ihrem atomaren Ansatz gehen Probleme mit dem Resourcenhandling ja gern schon mal durch.

In diese Rictung bewege ich mich gerade auch: im einfachen Uint Test funktioniert es, in der Anwendung nicht, also nach dem Unterschied suchen: ich versuche, die Unit Tests so umzubauen, dass sie auch die Host-App imitieren; allerdings soweit nichts gefunden.