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.

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!

Zitat von mpeg2

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.

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

Zitat von kingcopy

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.

Zitat von kingcopy

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.

Zitat von benben

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.

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.

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!