Beiträge von Thunder

Zitat von Christian

Wenn das aber so einfach ist, dann kann das natürlich jedem passieren, der einen relativ gängigen Benutzernamen verwendet.

Nur weil jemand versucht sich mit einem bestimmten Namen bzw. Benutzernamen im Forum anzumelden und dann womöglich probiert, ein neues Passwort zu erhalten, heißt das ja nicht, dass es einfach ist sich "einzuhacken". Offensichtlich stellt sich derjenige ja ziemlich hilflos an.

Ich kann die Liste mit erfolglosen(!) Logins ins Forum eine Zeit lang einsehen. Da sind immer massenweise Loginversuche, wo Leute denken, dass sie ihr Postfach "kontaktieren" bzw. die zugehörigen Logindaten verwenden, wie ich vermute. Diese Liste lässt mich nichts Gutes über das grundlegendste technische Verständnis vieler Anwender vermuten. Warum sage ich dies so? Weil ich vermute, dass einfach jemand unwissentlich das Login versucht. Dafür gibt es im Log der Fehlversuche Indizien.

axddxiss schreibe mich per Konversation an und nenne mir einen abgeänderten Usernamen, den ich im System für dich eintragen kann. Vielleicht hat das Leid dann ein Ende.

Ich schaue es mir heute Abend in Ruhe an.

Moin!

Mir ist bewusst, dass irgendwann auf monatliche(?) Releases umgestellt werden soll und, dass dann jede Versionsnummer wohl tatsächlich für Endanwender veröffentlicht werden soll. Aber momentan frage ich mich, ob 125.0 nun wirklich der öffentliche Start dafür ist? Release Notes gibt es jedenfalls derzeit noch nicht für 125.0 und mir fehlt gerade auch der passende Beitrag auf einem der News-Kanäle, weil ich diesen womöglich nicht "auf dem Schirm" habe?

Deshalb habe ich den Download der finalen Version erstmal auf 115.10.1 zurück gestellt.

Hast Du nochmals alle Prozesse des Thunderbird zwangsweise beendet? Wenn nein, dann versuche es damit nochmals, und schaue was dann passiert.

Ich kann den Bug im Zusammenhang mit "Papierkorb beim Beenden leeren" leider auch bestätigen. Wenn man dies in den Konten-Einstellungen für alle Konten deaktiviert, schließt sich Thunderbird wieder korrekt und lässt sich dann letztlich auch problemlos wieder starten. Das wohl bald erscheinende Update auf 115.10.1 wird das Problem dann hoffentlich beheben.

Vermutlich wird unter LInux in diesem Fall weiter die tabellarische Nachrichtenliste angezeigt? Ist dies mit dem alten UI gemeint? Zeige uns doch einfach mal (anonymisierte) Screenshots im Vergleich.

Ich habe das verantwortliche Element im Beitrag des "Embed" gefunden (und entfernt). Warum genau das passiert, kann ich nicht sagen. Vermutlich ergänzen mal wieder die Browser ein "fehlendes" HTML Closing-Tag, was zu dem letztlich zerschossenen HTML der Seite geführt hat.

Mhhh, das muss ich mir mal auf dem Desktop im HTML ansehen, was da passiert. Ich melde mich die Tage nochmal dazu.

Zumindest beim "modernen" Cardview statt der Spaltendarstellung ist das Problem doch überschaubar. Man muss halt abhängig vom gerade verwendeten Bildschirm eine Breite anpassen. Bei der "alten" Darstellung mit allen möglichen Spalten im Bereich der Themenliste, war dann immer wieder die Breite der ganzen Spalten zerschossen. Da musste man viel aufwändiger die Breiten wieder anpassen. Insofern sehe ich das hier nicht so kritisch - obwohl ich selbst teilweise davon betroffen bin.

In dem Zusammenhang muss man evtl. folgenden Bug im Blick haben, der in 115.8.0 behoben sein soll:

Naja, inzwischen bieten eine ganze Reihe von Web-Mail-Anbietern eine Funktion, die letztlich (in Wahrheit) einfach verzögert sendet. Ich sehe das letztlich so, dass wir uns dadurch leider immer mehr abgewöhnen, vor dem Senden "den Kopf einzuschalten". Es wäre doch überhaupt kein Problem, vor dem Senden eine "Qualitätskontrolle" zu machen. Wer sich das (Kontrolle vor dem Senden) angewöhnt, hat es hinterher leichter.

Im Fall von Outlook in Kombination mit Exchange-Server handelt es sich ja tatsächlich um eine "Fern-Lösch-Funktion", die man so lange verwenden kann wie das Gegenüber die Mail noch nicht geöffnet/gelesen hat. Sowas funktioniert aber eigentlich nur im Firmennetzwerk zuverlässig.

Und dennoch ist es unplausibel, warum diese Fehlermeldung kommt und vor allem auch warum diese einen solchen Begriff verwendet.

Windows 10 lässt es scheinbar teilweise (auch bei bspw. Outlook-Anwendern) nicht zu, dass man Attachments direkt auf dem Desktop speichert. Lege einen Ordner auf dem Desktop an und speichere die Anhänge darin, so wird es vermutlich funktionieren. Siehe dazu auch hier:

Beitrag

RE: Kein Speichern "alle Anhänge" möglich

Ich habe es jetzt ausprobiert, einen neuen Ordner auf dem Desktop angelegt und zwei Anhänge einer E-Mail problemlos abgespeichert. Allerdings war nicht mehr auf Anhieb zu erkennen, dass es sich um pdf-Dateien handelte. Nachdem das aber klar war, konnte ich beide Dateien mit dem pdf-Reader öffnen.

Also tatsächlich verhindert damit Windows 10 das Abspeichern von Anhängen direkt auf dem Desktop.

Danke für die helfenden Hinweise.

mgraeme

21. April 2020 um 21:31

Zitat von tiekla

Das Profil und die Mail-Dateien liegen auf einem Netzlaufwerk (Synology NAS) mit 500 GB freiem Platz.

Als erste Maßnahme solltest Du testweise ein Profil komplett lokal auf einem PC (ohne NAS!) erstellen. Ich wette, dass die Probleme dann weg sind. Falls sie dennoch noch vorhanden sind, mache Dir vorsichtshalber bewusst, dass Thunderbird überhaupt nicht damit klar kommt, wenn irgend eine gerade notwendige Datei im Profil nicht erreichbar ist. Dann wird nämlich sofort eine leere neue Datei erstellt. Dabei können von einzelnen Mails über ganze Mail-Ordner bis hin zum Totalverlust des Profils auftreten.

So, um es klar und deutlich zu sagen:

Es wurden (mehrere) Verwarnungen erteilt, denen ich voll und ganz zustimme.

Wir wollen die ewigen Sticheleien und Provokationen weder von Hilfesuchenden sehen, noch von "altverdienten" Helfern. Reißt Euch zusammen und verzichtet auf Beiträge, wenn Euch der Stil der Themenstarter nicht gefällt. Es kann nicht Sinn des Forums sein, dass hier von allen möglichen Leuten massenweise Offtopic-Beiträge geschrieben werden, die den eigentlichen Zweck des Forums völlig ins Abseits stellen.

Ich habe das Template jetzt selbst wieder mit dem fehlenden Code ergänzt, um das alte Verhalten wieder zu haben:

					<div class="wbbBoardNode__badge"{if !$subBoardNode->getUnreadThreads()} hidden{/if}>
						<span class="badge badgeUpdate" role="status" aria-label="{lang unreadThreads=$subBoardNode->getUnreadThreads()}wbb.board.unreadThreads{/lang}">{#$subBoardNode->getUnreadThreads()}</span>
					</div>

Ihr habt also die Anzahl der ungelesenen Beiträge/Themen wieder wie gewünscht in der Forenübersicht.

Sieht so aus, als würde WoltLab an dem Verhalten nichts ändern wollen. Ich müsste also selbst Hand anlegen.

Das Problem wurde nun doch schon zeitnah behoben.

Das Problem wird seitens WoltLab mit dem nächsten Update (Mitte Februar) behoben:

Link ohne Protokoll zeigt auf localhost - WoltLab®

Link im Editor erstellen Als Linkziel eine Sprungmarke wie bspw. #foobar nehmen Geparst ist die URL aktuell https://localhost/#foobar während sie in 5.x noch…

www.woltlab.com

Ich könnte die URLs natürlich jetzt alle nachträglich hier im System ändern, möchte aber erstmal abwarten, was an Rückmeldung kommt.