QuickIO: Es findet nur eine Teilkopie statt.

Guten Tag zusammen,

aufgrund der eher geringen Kopiergeschwindigkeit von seitens System.IO bin ich während der Suche nach einer Alternative auf QuickIO gestoßen. Die Geschwindigkeit ist grandios. Leider gesellt sich hier ein Problem hinzu, für das ich keine Antwort finden kann. Bei einem Kopiervorgang eines einfachen Verzeichnisses werden diverse Dateien nicht mitkopiert. Die Fehlermeldung lautet immer The system cannot find the path specified. Hierbei handelt es sich um ganz gewöhnliche benannte Dateien (.xlsx, .pdf etc.)

Die Quelldaten existieren, sowie auch das Zielverzeichnis.
Aufgerufen wird das Ganze mit

var copy = new QuickIOTransferDirectoryCopyService(new QuickIODirectoryInfo( @"C:\tmp1"), @"C:\tmp2",1,3, System.IO.SearchOption.AllDirectories); 

copy.FileCopyError += copy_FileCopyError;

await copy.StartAsync();

Im Gegensatz dazu wird ein separates Kopieren einer angeblich nicht gefundenen Datei ohne Beanstandung erfolgreich durchgeführt.

QuickIOFile.Copy(@"C:\tmp1\meineDatei.xlsx", @"C:\tmp2\meineDatei.xlsx", false);

Ich habe ebenfalls andere Verzeichnisse und Clients probiert. Das Ergebnis ist das gleiche und ich kann mir keinen Reim darauf machen.

Grüße

Die Bibliothek ist von mir.

Wo genau tritt der Fehler auf und wie sieht die tatsächliche Struktur aus?
QuickIO verwendet direkt die Win32 API. Die Meldung kommt also vermutlich eher von Windows (bzw. wird dort ausgelöst), als von QuickIO.

PS + FYI: System.IO ist langsam, weil viele Daten geladen werden, ohne, dass sie meist genutzt werden (pre-fetching).
Kopieren selbst dürfte kaum Unterschied machen; vor allem beim Lesen zeigt QuickIO eine höhere Performance.

Parallel schreiben macht ohnehin nur sehr selten Sinn.
Auf lokalen Platten wirkt sich paralleles Schreiben sogar negativ aus.

Hallo,

die Struktur (ich vermute dass damit das Verzeichnis gemeint ist) ist wirklich ein einfacher Verzeichnisbaum mit Office-Dokumenten. Ich habe ebenfalls andere Testumgebungen probiert (z.B. im privaten Bereich mit dem gleichen Resultat).

Die Fehlermeldungen sammle ich über das Event FileCopyError(object sender, QuickIOTransferFileCopyErrorEventArgs e).

Ich habe im Anhang ein Logfile beigefügt, das die Meldungen einer Testkopie beinhaltet.

Mit dem Parallel hast Du recht. Habe dieses auch bereits korrigiert. Was die Lesegeschwindigkeit angeht, so bin ich echt begeistert und erstaunt, wie schnell unsere Fileserver ausgelesen werden können.

Grüße

Bei einem FileServer ist paralleles Schreiben i.d.R. schneller, weil er einen entsprechenden Aufbau hat, das auf Parallelität optimiert ist - sowohl das System wie auch die Platten (Controller, RAIDS, Multi-Stream...).

Bei diesem Job passiert folgendes:

• Analyse der vorhandenen Struktur (Ordneraufbau und Dateien)
• Erstellen aller Ordner im Zielverzeichnis
• Transferieren aller Dateien

Damit spart man sich das Prüfen jeder einzgelnen Dateien und Ordnern, das unter Windows immer ein Handle benötigt und daher relativ langsam ist.
Problem: FileServer kommen manchmal nicht hinterher; daher kann es in diesem Fall (bewusst) zu Race Conditions kommen - leider by Design.

Das bedeutet, dass QuickIO zwar die Ordner erstellt; weil das aber sehr schnell passiert meldet dann Windows beim Schreiben der Datei, dass der Zielordner nicht existieren würde.
Damals hatte ich aber keine Zeit das zu Lösen; wir haben damals einfach die Worker runter geschraubt und quasi leider künstlich verlangsamt.

Der Fehler kann prinzipiell auch nur beim Schreiben passieren, weil der Job eben selbst nicht prüft. Im Gegensatz zum Idiotensicheren System.IO prüft eben QuickIO gewisse Dinge nicht von selbst weil das von Haus aus eben Performance kostet.
Daher muss der Fehler an dieser Stelle von Windows oder dem anderen System kommen.

Guten Morgen,

Danke für das Feedback. Das würde erst einmal quasi als Workaround bedeuten, dass ich die Zeitspanne nach der Erstellung der Verzeichnisse und dem Beginn des Dateikopiervorganges erhöhen muss. Hierzu würde ich gerne den SourceCode anpassen wollen. Leider finde ich aber auf GitHub offensichtlich eine andere SourceCode-Version vor als die dll von NuGet. Ich kann die Klassen wie _QuickIOTransferDirectoryCopyService _etc. im Sourcecode nicht finden und der Object Browser/ dotPeek zeigt ebenfalls Unterschiede zwischen der DLL von NuGet und dem Sourcecode von GitHub an.

Grüße

Ich war gestern selbst etwas verwundert über den Stand auf GitHub; das Projekt war damals auf CodePlex - wurde aber im Rahmen dessen Shutdown wohl von mir nicht ganz migriert...

Ich hab gestern aus meinem lokalen Backup alle vorhandenen, damals nicht in Git sondern in TFVC geführten Stände als Git Branches auf GitHub geschoben.
Schaust also mal in die Branch Ansicht in GitHub; zu meiner Schande suche ich ehrlich gesagt selbst gerade die 2.6.x Version - weiß nicht wieso das nicht sauber migriert hat.

Hallo,

das wäre dann die Version 2.0.1.0. Ich arbeite erst einmal damit und schaue von Zeit zu Zeit nach, ob Du die 2.6er gefunden und veröffentlicht hast. Danke für die Mühe.

Grüße

Damals hat sich zwischen den Versionen nicht sonderlich viel getan; da hab ich noch kein SemVer und kein GitVersion verwendet (weil CodePlex -> TFVC).

Hallo,

kurz ein Feedback zur Version 2.0.1.0

Ich habe die jetzt getestet und stellte fest, dass der Kopiervorgang unter dieser Version zu meiner Begeisterung tadellos funktioniert und die Fehler nicht reproduzieren konnte.

Grüße

🤔

Seid ihr beide der gleiche Mensch hinter den zwei Benutzern...?
Oder ist das ein Feedback für eine Nachstellung der Situation..?

Hallo Abt,

wir sind zwei unterschiedliche Personen.

Das war nur ein Feedback von mir, da ich durch diesen Thread auf QuickIO gestoßen bin und hier offenbar meine Suche nach einem schnelleren Kopieren endet. Ich habe das PRoblem, das ich Daten
zwischen zwei Sharepoints migrieren muss. Mit dem Windows Explorer und System.IO ist das leider z.Z. extrem langsam. Mit QuickIO geht das bedeutend zügiger, was mich echt begeistert 😃

Btw: Mit der 2.6 habe ich das gleiche Problem wird der Quia_Respexit, wobei 2.0.1.0 bei mir lübbet.

@DerPapenberg
Und robocopy war dafür keine Option?
Ich kopiere damit teilweise mehrere Gigabyte über 1GBit Leitung ohne Probleme.
Hier ist sogar die Platte der limitierende Faktor, da diese nicht mit dem schreiben hinterher kommt.
Gerade wenn man viele/große Dateien kopieren will, ist der Explorer absolut unbrauchbar.

Robocopy ist gerade unter Windows ein gutes Gegenstück zu rsync, auch wenn Robocopy hier nicht einfach via SSH Verbindung Daten kopieren kann.
Aber eine Mirror Funktion und eingie weitere Optionen zum Include/Exclude sind an Bord.

T-Virus

Btw: Mit der 2.6 habe ich das gleiche Problem wird der Quia_Respexit, wobei 2.0.1.0 bei mir lübbet.

Danke, schau ich mir an.

Guten Abend zusammen,

@T-Virus,

leider ist Robocopy und andere Tools keine Option. Auf dem Quell-Sharepoint sind Dateien mit gewissen Zeichen erlaubt, die auf dem Ziel-Sharepoint nicht erlaubt sind (untschiedliche Verantwortlichkeiten und Richtlinien ). D.h, es muss auch noch eine Umbenennung und teilweise ein Zippen stattfinden, da auf dem Ziel-Sharepoint zusätzlich manche Dateiarten nicht gespeichert werden können (accdb und viele weitere). Aufgrund der schieren Masse kann das nur automatisiert gehen. Am liebsten würde ich einen reinen Fileserver hochziehen, aber ich bin nicht der Kostenstellenverantwortliche 😉
Wenn das nicht wäre, hätte ich die Daten bereits mit Robocopy, TotalCommander etc. übers Wochende migriert. Somit muss ich eine eigene Lösung schaffen, die bereits einwandfrei funktioniert. Der Knackpunkt war bis jetzt leider nur die sehr geringe Geschwindigkeit des Ziel-Sharepoints. Mit QuickIO
geht das bedeutend flotter, auch wenn eine normale Geschwindigkeit momentan noch nicht gegeben ist (wahrscheinlich ein Sharepoint in der VM mit einem Minimum an Ressourcenzuweisung 😁 ).

Hallo,

auch ich konnte jetzt die 2.0.1er testen. Funktioniert.

Grüße