eine ursache für leere mails gefunden

  • user A hat eine regel die alle mails an user B, C, D kopiert. funktioniert auch

    user B hat urlaub und verteilt auf user C.

    user C bekommt somit die mails doppelt. ok. löscht oder verschiebt er eine der beiden mails ist die andere auch weg (eintrag noch da, aber kein inhalt)

    meine vermutung ist das beim verteilen von A auf BCD die mail den gleichen dateinamen hat.
    beim verteilen von B auf C wird die datei überschrieben und ist dann nur moch einmal da.
    nach dem eine mail gelöscht wurde ist dann nix mehr da.

    user A ist kein realer benutzer, sondern eine sammeladresse. vielleicht gibts geschicktere möglichkeiten das zu lösen (vorschläge willkommen), ändert aber nix an dem fehler.

  • Zitat

    user C bekommt somit die mails doppelt. ok. löscht oder verschiebt er
    eine der beiden mails ist die andere auch weg (eintrag noch da, aber
    kein inhalt)

    User C soll mal eine Nacht warten bevor er eine Email Verteilt, nachdem die Datenbereinigung durchlief.

    Ergebnis?

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • antwort von tobit:
    Guten Tag, Herr xxxx. In der Tat ist es so, dass sich der physikalische Name der Nachricht beim Verteilen nicht ändert. Wird also durch mehrere Regeln die gleiche Nachricht mehrmals in einen anderen Ordner verschoben, wird jeweils ein Eintrag in der archive.dat angelegt. Die eigentliche Datei wird dabei aber jeweils überschrieben. Somit werden im David Client mehrere Einträge angezeigt, die auf die selbe Datei verweisen.

    zu deutsch: is halt so.

  • Mach Dir nichts draus - in anderen Konstallationen hat man die Mails dafür unnötigerweise doppelt und dreifach. Das gleicht sich doch aus?

    t'is no bug t'is a feature!

  • user A hat eine regel die alle mails an user B, C, D kopiert.


    servus,

    ich würde gerne kurz wissen aus welchem organisatorischen grund man so eine lawinenschaltung macht. kann ich was lernen? ?(^^

    thx

    "Programming today is a race between software engineers striving to
    build bigger and better idiot-proof programs, and the Universe trying
    to produce bigger and better idiots. So far, the Universe is winning."

  • user C bekommt somit die mails doppelt. ok. löscht oder verschiebt er eine der beiden mails ist die andere auch weg (eintrag noch da, aber kein inhalt)


    Das ist natürlich gefährlich, wenn man doppelte Nachrichten hat löscht man wohl erstmal eine davon. Wenn dann die Zweite dadurch unbrauchbar wird hat man keine mehr......

  • "user A ist kein realer benutzer, sondern eine sammeladresse. vielleicht gibts geschicktere möglichkeiten das zu lösen (vorschläge willkommen), ändert aber nix an dem fehler."

    wie kann ich es denn besser lösen das mails an eine sammeladresse (z.b. info, marketing, etc...) an mehrere benutzer gehen.
    hab keine bessere möglichkeit gefunden als einen richtigen benutzer anzulegen.

  • Wir haben wieder leere Emails:

    Nutzer A) [Verteilt] eine email aus seinem Eingang an seinen Nachbarn User B) [Original zustellen]

    Die Email ist bei Nutzer B) LEER kein Inhalt und auch kein Attachment mehr.

    sorum hatte ich das auch noch nicht.

    zum Glück hatte die [Strongbox] noch eine Kopie von gestern um 14:47

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • "[Verteilt]" heißt über die "Verteilen"-Funktion, die man per Rechtsklick erreicht?

  • Nutzer A) [Verteilt] eine email aus seinem Eingang an seinen Nachbarn User B) [Original zustellen]

    Die Email ist bei Nutzer B) LEER kein Inhalt und auch kein Attachment mehr.


    Das Problem hatten wir gelegentlich, wenn Faxe zu schnell aus unverteilt an einen Benutzer zugestellt wurden.

  • Manuelles Verteilen mit Rechtsklick (original zustellen) Keine automation.

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • Manuelles Verteilen mit Rechtsklick (original zustellen) Keine automation.

    Sollten die User eigentlich so gemacht haben, kommt allerdings in seltenen Einzelfällen trotzdem leer an, wobei ich nicht genau sagen kann, was die User wie gemacht haben. Vielleicht haben sie auch vorher die Nachricht zwischen einzelnen Archives verschoben, um sie dann doch zu verteilen. Im Nachhinein ist das kaum festzustellen.

    Bei Nachrichtenverlusten sollte man grundsätzlich jegliche Automation auf ein notwendiges Minimum reduzieren, vielleicht sogar alle Archivierungsregeln erst einmal abschalten, um zu sehen, ob es dann besser wird.

  • Dürfte ja trotzdem nicht passieren. Bei Kingcopys Vorgehen wird ja immer der selbe Vorgang durchgeführt: SL.exe erzeugt die Datei im Zielverzeichnis, passt die archive.dat an und löscht die Dateien im Ausgangsordner (bzw. vorher bereits). Das Eintragen in die archive.dat scheint ja funktioniert zu haben, sonst wäre die Nachricht nicht in der Eintragsliste. Es muss also etwas vorher passiert sein mit den Dateien. Bleiben ja nicht viele Möglichkeiten. Konnten nicht übergeben werden, konnten nicht erzeugt werden, wurden nach dem erzeugen gelöscht. Warum und wodurch, ist eine andere Frage. Dadurch dass es nur sporadisch auftritt, macht das ganze ja leider nicht einfacher. Vielleicht lässt sich mit dem Process Monitor was erkennen, auch wenns nur sporadisch auftritt.

  • Dürfte ja trotzdem nicht passieren. Bei Kingcopys Vorgehen wird ja immer der selbe Vorgang durchgeführt: SL.exe erzeugt die Datei im Zielverzeichnis, passt die archive.dat an und löscht die Dateien im Ausgangsordner (bzw. vorher bereits). Das Eintragen in die archive.dat scheint ja funktioniert zu haben, sonst wäre die Nachricht nicht in der Eintragsliste. Es muss also etwas vorher passiert sein mit den Dateien. Bleiben ja nicht viele Möglichkeiten. Konnten nicht übergeben werden, konnten nicht erzeugt werden, wurden nach dem erzeugen gelöscht. Warum und wodurch, ist eine andere Frage. Dadurch dass es nur sporadisch auftritt, macht das ganze ja leider nicht einfacher. Vielleicht lässt sich mit dem Process Monitor was erkennen, auch wenns nur sporadisch auftritt.

    Es geht mehrere 1000x gut und dann dreimal nicht. Theoretisch funktioniert alles, scheint aber einfach architekturbedingt anfällig. Der nächste Schritt überprüft offensichtlich nicht zuverlässig, ob der vorherige auch korrekt durchgeführt und beendet ist. Und dann ist die Ganze Struktur inkonsistent, was im Datenbankbereich dem Verlust der referenziellen Integrität entspchäche. Vielleicht liegen im ungünstigen Fall noch Dateisperren im Millisekundenbereich zu lange vor oder ähnliches. Genaues kann nur Tobit sagen.

    Das Problem träte wahrscheinlich nicht auf, wenn der Vorgang in einer Datenbank unter Einbeziehung einer Transaktionssteuerung liefe. Dann gäbe es bei einem eventuellen Abbruch ein Rollback und der Ausgangszustand wäre wiederhergestellt. So macht das jede vernünftige kaufmännische Lösung. Das gab es schon mindestens in den 80er des vorigen Jahrhunderts. Aber die Architektur mit den einzelnen gestückelten Dateien läßt läßt so etwas nicht zu, wenn es nicht aufwändig in der Anwendung programmiert wird.

  • Naja, dann einfach mal mit Tobit sprechen, so wie wir das gerade machen (ohne Vorwürfe). Die können sicher was an der Toleranz von David drehen. Wie man in anderen Threats lesen kann, wurde es mit den leeren emails und Abstürzen, mit den letzten SPs ja auch sehr viel besser, wenn nicht sogar ganz vorbei, was dafür ein Zeichen ist. Wäre doch eine Idee.

  • Zitat

    Es geht mehrere 1000x gut und dann dreimal nicht.
    Theoretisch
    funktioniert alles, scheint aber einfach architekturbedingt anfällig.
    Der nächste Schritt überprüft offensichtlich nicht zuverlässig, ob der
    vorherige auch korrekt durchgeführt und beendet ist.

    besser kann man es nicht sagen.

    es gibt da diesen watchdog delay....

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • Ola,

    gibts in dieser Sache was neues?

    Wir haben nämlich das Problem auch wieder.
    Dachten eigentlich mit dem Update letztes Jahr von David 10 auf FX, dass das Problem erledigt sei.....
    Jetzt, seit ca. 3 Wochen, taucht das Problem sporadisch wieder auf.

  • Da es ja scheinbar einige Gründe für die leeren mails geben kann, musst du erstmal bei euch weiter eingrenzen. Wie in andern Threads zu lesen ist, kann es auch am RAID Controller, Schattenkopie, bestimmtem Vorgehen, bestimmten Funktionen usw. liegen. Allgemein zu fragen: Gibts was neues, lässt sich schwer beantworten, weils ja von Installation zu Installation was andres sein kann.

  • Wir hatten das Problem schon mit David 10. Dort hatten wir direkte Hardware, also nichts Virtualisiert. W2K3 war als Host System am laufen.

    David FX wurde dann komplett neu, auf einer Virtuellen, Server 2008 Maschine installiert. User wurden komplett neu angelegt, Archive neu erstellt. Das einzige was ichvom alten System übernommen habe, sind die Mails der 70 User, die ich per Strongbox übertragen habe.
    Eine andere Lösung von Virensoftware wird eingesetzt.

    Das was sich gleicht, ist die Tatsache, das dieses Problem beim verteilen der Mails auftaucht.
    Am alten System ging es sogar am schluss soweit, das 70% aller Wiedervorlagen der User einfach Blanko waren.


    UNd wie gesagt, dies Probelm taucht erst seit 3 Wochen wieder auf. Geändert wurde von meiner Seite aus defenitiv nichts!

  • Das ist der Geist in der Maschine, kommt ab und zu , kann man nichts machen.

    die Ausgänge dürfen nicht angefasst werden. Als Haupttipp.

    Ist bei uns auch ab und an und das schon über 3 Server Generationen verschiedener Bauarten.

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!