Gestern bin ich über ein interessantes Phänomen gestolpert, das ich mir nicht recht erklären konnte. Die Aufgabe war einfach:
- Aus einem Verzeichnis alle Dateien löschen, die einem bestimmten Filter entsprechen
- Nach dem Löschvorgang die Anzahl der tatsächlich gelöschten Dateien ausgeben
Also erst alle zu löschenden Dateien in einem IEnumerable<string> sammeln und anschließend über File.Delete(…) in einer foreach-Schleife löschen.
Das Problem
Das Problem war nun, dass nach dem Durchlaufen der foreach-Schleife, das IEnumerable keine Einträge mehr enthielt. Es war einfach leer! Somit war die Ausgabe der Anzahl nicht mehr möglich.
Der Workaround dazu ist natürlich, die Anzahl vorher zu merken und anschließend auszugeben.
Das Problem hat mich aber weiter beschäftigt. Es wollte sich mir nicht erschließen, warum das IEnumerable leer sein sollte. Es enthält doch nur die Liste von Dateinamen!
Die Tests
Also habe ich mich dem Problem mit einer Reihe von Unit-Tests genähert.
Der erste Test durchläuft eine IEnumerable und gibt die Werte auf der Console aus:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public void TestIterationOfIEnumerable() { IEnumerable<string> sut = new string[] { "TextFile1.txt", "TextFile2.txt" }; sut.Count().Should().Be(2); foreach (var item in sut) { Console.WriteLine(item); } sut.Count().Should().Be(2); } |
Dieser Test ist – wenig überraschend – erfolgreich.
Im zweiten Test habe ich nun das Löschen mit aufgenommen.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public void TestIterationOfIEnumerableOfStringArrayWithFileDeletion() { IEnumerable<string> sut = new string[] { @"FilesToDelete\TextFile1.txt", @"FilesToDelete\TextFile2.txt" }; sut.Count().Should().Be(2); foreach (var item in sut) { File.Delete(item); } sut.Count().Should().Be(2); } |
Auch dieser Test läuft ohne einen Fehler durch.
Als Ursache Ausschließen können wir also die foreach-Schleife an sich und auch der Aufruf von File.Delete(…) führt nicht zu einem Fehler.
Die nächste Besonderheit im ursprünglichen Code war, dass wir für die Zusammenstellung der Dateien Linq verwendet haben.
Der nächste Test verwendet also Linq um das IEnumerable zu erzeugen.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
public void TestIterationOfIEnumerableOfStringArrayUsingLinqWithFileDeletion() { IEnumerable<string> sut = FetchFilesFromStringArray(new string[] { @"FilesToDelete\TextFile1.txt", @"FilesToDelete\TextFile2.txt" }); sut.Count().Should().Be(2); foreach (var item in sut) { File.Delete(item); } sut.Count().Should().Be(2); } private IEnumerable<string> FetchFilesFromStringArray(string[] files) { return from file in files select file; } |
Aber auch dieser Test bleibt grün, alles ist in Ordnung, das IEnumerable bleibt unverändert.
Ein weiterer Blick in den ursprünglichen Code zeigt nun, dass zum Füllen der IEnumerable kein einfaches string[]-Array verwendet wird, sondern eine Hilfsfunktion von Directory in Verbindung mit einem Linq-Ausdruck.
Diesen Code wollte ich also auch ausprobieren. Dazu musst ich aber nun tatsächlich das Verzeichnis „FilesToDelete“ mit den entsprechenden Dateien anlegen und im Visual Studio als „Copy if newer“ markieren.
Der Code des Tests sieht nun wie folgt aus:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
public void TestIterationOfIEnumerableOfDirectoryEnumerationUsingLinqWithFileDeletion() { IEnumerable<string> sut = FetchFilesFromDirectory("FilesToDelete"); sut.Count().Should().Be(2); foreach (var item in sut) { File.Delete(item); } sut.Count().Should().Be(2); } private IEnumerable<string> FetchFilesFromDirectory(string directory) { return from file in Directory.EnumerateFiles(directory) select file; } |
Und siehe da…der Test schlägt tatsächlich fehl! Die Ursache liegt also irgendwo in diesem Code versteckt.
Ein weiterer Test sollte nun (das hier ohnehin sehr überflüssige) Linq als Ursache ausschließen.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[TestMethod] public void TestIterationOfIEnumerableOfDirectoryEnumerationWithFileDeletion() { IEnumerable<string> sut = Directory.EnumerateFiles("FilesToDelete"); sut.Count().Should().Be(2); foreach (var item in sut) { File.Delete(item); } sut.Count().Should().Be(2); } |
Auch dieser Test schlägt fehl! Ha, es liegt also am Aufruf von Directory.EnumerateFiles(…).
Die Ursache
Aber warum wird die Liste im IEnumerable bei der Verwendung der Methode Directory.EnumerateFiles(…) nach dem Löschen der Datei geleert?
Ein Blick in den Source-Code der Directory-Klasse des .Net Frameworks zeigt die Ursache auf. Über einen recht langen Stacktrace wird irgendwann ganz unten in einer Factory folgender Code aufgerufen:
|
1 2 3 4 5 6 7 |
internal static IEnumerable<String> CreateFileNameIterator(String path, String originalUserPath, String searchPattern, bool includeFiles, bool includeDirs, SearchOption searchOption, bool checkHost) { [...] SearchResultHandler<String> handler = new StringResultHandler(includeFiles, includeDirs); return new FileSystemEnumerableIterator<String>(path, originalUserPath, searchPattern, searchOption, handler, checkHost); } |
Es wird also kein IEnumerable über eine Liste von Strings erstellt, mit dem wir arbeiten, sondern es wird ein FileSystemEnumerableIterator<String> erstellt. Dieser wiederum ist so implementiert, dass er intern immer über die Methode Directory.GetDemandDir(…) auf das Dateisystem zugreift.
Nach dem Löschen sind die Dateien um Dateisystem natürlich nicht mehr vorhanden, weshalb die Liste in unserem obigen Test dann leer ist.
Zusammenfassung
Sicher lässt sich dieses Verhalten für andere Zwecke gut nutzen. Für den o.g. Zweck, allerdings nicht.
Nun, dann bleibt mir noch, Microsoft dafür zu danken, dass sie den Source-Code des .Net-Frameworks zur Verfügung gestellt haben, ohne den ich darauf sicher niemals gekommen wäre und mir für das Herausfinden selbst auf die Schulter zu klopfen.
Jetzt trinke ich mir erstmal den verdienten Kaffee und versuche beim nächsten Mal im Debugger früher auf den Typ der Interfaceimplementierung zu achten. Die war nämlich schon die ganze Zeit sichtbar…ich hätte nur hinschauen müssen:
