none
FileWrite-Zugriff wird durch FileRead-Zugriff gestört RRS feed

  • Frage





  • Hallo Forum,
    eine Frage an die File-Spezialisten unter euch:
    gibt es eine Möglichkeit lesend auf ein File so zuzugreifen, dass der schreibende Prozess dadurch nicht gestört wird ?

    Hintergrund: ich habe eine feste Applikation, die kontinuierlich Meßwerte im Sekundentakt in eine File wegschreibt. Auf dieses File würde ich gerne live zugreifen, um diese über meine Anwendung weiter zu verarbeiten. Leider ist die Meßsoftware sehr empflindlich. Wenn ich lesend auf das File zugreife in dem Augenblick in dem die Meß-Applikation in das File schreibt, bekomme ich einen Fehler in der Meßsoftware. Ich habe schon die verschiedensten Versuche gemacht.
    Die Konstellation ist die folgende: die Meßsoftware läuft auf einem PC, meine Software läuft auf einem zweiten PC und greift per Netzwerk auf die Daten zu.

    Im ersten Schritt hatte ich direkt auf den im Netzwerk nur mit Read-Rechten freigegebenen Ordner gelesen. Das hat aber öfter gestört wenn z.B. das Netzwerk mal längere Latenzzeiten hatte.Der Zugiff unter .net VB 2003 erfolgte mit:

    Dim FS As System.IO.FileStream
    FS = System.IO.File.Open(Target, IO.FileMode.Open, IO.FileAccess.Read)

    Do While
    ..... byteweise lesen
    Loop Until .... letzes Byte

    Jetzt läuft auf dem Meß-PC ein lokales Batch-Script, dass die Dateien per COPY in einen zweiten Ordner zyklisch je Sekunde wegkopiert. Von dort ziehe ich mir die Daten. Da das Script lokal arbeitet, sind die Zugriffzeiten kürzer und die Wahrscheinlichkeit geringer, dass sich beide Prozesse treffen. Trotzdem bekomme ich über den Tag verteilt immer noch 3-4 Fehler bzgl. Zugriff beim Schreiben der Daten. Das Script lautet:

    @echo off
    :Start
    CLS
    ECHO *******************************************
    xcopy /C /Y C:\data\data.csv C:\info
    ECHO *******************************************
    ping localhost > nul
    goto Start

    Da ich jetzt in der zweiten Lösung mit COPY arbeite, frage ich mich: wie arbeitet der COPY-Befehl ? Führt dieser auch die Kopieraktion im lesenden Zugriff durch, oder wie ?

    Ich hatte immer geglaubt, wenn ich nur lesend auf ein File zugreife der Schreibprozess dadurch nicht gefährdet ist. Allenfalls bekomme ich halt nur Schrott beim Lesen, wenn das File z.B. nur aus 0kByte oder einem angefangenen Header besteht, aber das kann ich zum Glück sauber abfangen dank deines deutlichen File-Terminators. Das Script wie auch die Meßsoftware läuft übrigens in einem Account mit lokalen Administratorrechten. Die zu lesende Datenmenge ist ca. 1 kByte.

    Habt Ihr eine bessere Lösung ?
    Habe ich was übersehen ?

    Vielen dank schon mal für euere Anregungen ...

    Grüße
    Markus



    Samstag, 15. August 2009 14:27

Antworten

  •  Hallo Markus,

    ich weiss zwar nicht ob es was bringt, aber hast Du mal versucht IO.FileAccess.Read auf ReadWrite zu setzen.

    Schöne Grüße
    Oliver
    Samstag, 15. August 2009 15:20
  • Hallo Steven,

    an der Stelle sind die Angaben anfangs nicht so leicht zu durchschauen.

    Die FileAccess Angabe gibt an, was Du mit der Datei anfangen darfst.

    Für maximale Kooperation solltest Du die Datei mit FileShare .ReadWrite eröffnen (Vorgabe ist None),
    denn darüber wird festgelegt, was andere Prozesse (oder auch parallel im Programm eröffnete Streams)
    mit der Datei anstellen dürfen:
    FS = System.IO.File.Open(Target, IO.FileMode.Open, IO.FileAccess.Read, FileShare.ReadWrite)
    dann dürfen andere Prozesse sowohl lesen als auch schreiben - letzteres kann die Datei zwischen
    zwei Aufrufen verändern.
    Und Du erhälst solange Zugriff wie der andere Prozess ebenfalls mindestens FileShare.Read erlaubt -
    copy wie xcopy sollten das eigentlich tun, wobei das CopyFileEx API auch Sperren ermöglicht

    Bei der Schleife solltest Du weitgehend blockweise arbeiten, damit die Zeit kurz gehalten wird.
    falls die Daten strukturiert sind, hilft ein BinaryReader

    Und für den Fall der Fälle solltest Du den FileStream in einem using Block verwenden,
    damit die Datei auf jeden Fall geschlossen wird.


    Gruß Elmar
    Samstag, 15. August 2009 18:33
    Beantworter

Alle Antworten

  •  Hallo Markus,

    ich weiss zwar nicht ob es was bringt, aber hast Du mal versucht IO.FileAccess.Read auf ReadWrite zu setzen.

    Schöne Grüße
    Oliver
    Samstag, 15. August 2009 15:20
  • Hallo Steven,

    an der Stelle sind die Angaben anfangs nicht so leicht zu durchschauen.

    Die FileAccess Angabe gibt an, was Du mit der Datei anfangen darfst.

    Für maximale Kooperation solltest Du die Datei mit FileShare .ReadWrite eröffnen (Vorgabe ist None),
    denn darüber wird festgelegt, was andere Prozesse (oder auch parallel im Programm eröffnete Streams)
    mit der Datei anstellen dürfen:
    FS = System.IO.File.Open(Target, IO.FileMode.Open, IO.FileAccess.Read, FileShare.ReadWrite)
    dann dürfen andere Prozesse sowohl lesen als auch schreiben - letzteres kann die Datei zwischen
    zwei Aufrufen verändern.
    Und Du erhälst solange Zugriff wie der andere Prozess ebenfalls mindestens FileShare.Read erlaubt -
    copy wie xcopy sollten das eigentlich tun, wobei das CopyFileEx API auch Sperren ermöglicht

    Bei der Schleife solltest Du weitgehend blockweise arbeiten, damit die Zeit kurz gehalten wird.
    falls die Daten strukturiert sind, hilft ein BinaryReader

    Und für den Fall der Fälle solltest Du den FileStream in einem using Block verwenden,
    damit die Datei auf jeden Fall geschlossen wird.


    Gruß Elmar
    Samstag, 15. August 2009 18:33
    Beantworter
  • Hallo Markus,

    Haben Dir die Antworten geholfen?

    Grüße,
    Robert

    Donnerstag, 27. August 2009 09:32
    Moderator
  • Hallo Markus,

    Ich gehe davon aus, dass die Antworten Dir weitergeholfen hat.

    Grüße,
    Robert

    Freitag, 28. August 2009 10:27
    Moderator
  • Hallo euch allen,
    vielen Dank erst mal für die schnellen Hilfen ... ich bin leider KEIN SO guter Forumsteilnehmer und brauche für meine Antworten immer etwas länger.

    Kurzer Status:
    - war 2 Wochen in Urlaub, daher die Sendepause
    - bin noch an der Baustelle drann, denn die Sache hakelt immer noch
    - von der FileShare-Option hatte ich mir viel versprochen, reichte aber noch nicht
    - die anderen Sachen habe ich in der kürze der Zeit nur mal angetestet, hat aber im ersten Blick auch nix gebracht
    - etwas mehr konnte ich erreichen, in dem ich von COPY/XCOPY im Script auf ROBOCOPY im Backupmode umgestiegen bin
    - diese Woche habe ich noch Streß mit anderen Projekten, werde mich aber anschließend wieder melden (nach gründlicheren Tests)

    Vielen Dank für alle Tipps und euer Interesse

    Bis die Tage ...

    Gruß
    Markus
    Dienstag, 8. September 2009 18:51