Windows: Kopier- oder Leseprogramm, das Dateien lesen kann, auch wenn Teile der Datei zwischenzeitlich write-locked werden

Ich habe folgendes Problem: Ich will eine ~7GiB große Logdatei einlesen und analysieren. Problem dabei: Die Applikation, welche die Logdatei beschreibt läuft derweilen noch, und schreibt alle paar Minuten Mal ein paar Zeilen raus. Tools wie das cmd.exe Builtin "TYPE" oder auch cat.exe aus CygWin können damit auf MS Windows irgendwie nicht umgehen.

CygWin Tools geben nach einer Zeit "Device or Resource busy" zurück und brechen ab. Native Windows Programme wie TYPE oder COPY in cmd.exe hingegen liefern diesen Fehler und brechen dann ebenfalls ab:

"Der Prozess kann nicht auf die Datei zugreifen, da ein anderer Prozess einen Teil der Datei gesperrt hat."

Was ich will: Die Funktionalität von TYPE oder cat.exe (Dumpen des Logdateiinhalts auf stdout) oder die Funktionalität von COPY, aber ohne von zwischenzeitlichen Write Locks unterbrochen zu werden. Am elegantesten wäre es, wenn das lesende Programm den Schreibzugriff erkennt, abwartet bis der Write Lock aufgehoben wird, und dann einfach weitermacht. Bevorzugt wäre die Funktionalität von TYPE/cat, damit ich keine temporären Dateien anlegen muß.

Gibt es sowas?

Spannend ist, daß mein FTP Server das kann. Läuft auf der selben Maschine. Wenn ich die Datei via FTP lade, geht das sauber durch und die Datei ist auf der herunterladenden Maschine genau so groß wie die Quelldatei zu Beginn des Transfers war. Das neu hinzugekommene lädt er einfach nicht.

Ich vermute daß es an der Art und Weise liegt, wie man liest, bzw. wie die Funktionalität des Lesens per Win32 API implementiert ist. Also daß es mehr eine API Sache als eine NTFS Sache ist.

sed kenne ich gut (sowohl GNU als auch BSD sed), benutze ich oft, gleich wie awk. Kann ich halt auch nur aus CygWin auskoppeln. Einen Versuch ist es vielleicht trotzdem wert, kann ja nicht schaden.

Edit: Leider, gleich wie cat: "read error", "Device or Resource busy". Ich vermute Mal das wird mit allen CygWin Tools so ausschauen.

Also, der Stream Editor und cat wollen nicht, aktuell teste ich einfach grep mit leerem Suchmuster. Das scheint zu klappen! Leider muß man die Ausgabe dann noch durch unix2dos pipen, weil er sonst die Zeilenumbrüche umwandelt (\r\n -> \n). Das kostet unnötig Speichertransfers und CPU Zyklen, aber ok. Das ganze ist sagenhaft langsam, ich messe grade die Zeit die es kostet um es über das komplette Logfile laufen zu lassen. Gut schaut's nicht aus, aber schaun wir Mal.

Eventuell kommt das Programm das die Daten mittels Pipe erhalten soll auch mit UNIX Zeilenumbrüchen zurecht, dann könnte ich zumindest den unix2dos-Schritt einsparen.

Wenn ich die Daten erst Mal verarbeitet habe, kann ich das Monsterlogfile wegschieben, mit kleineren Files weiterarbeiten und öfter rotieren.