Die kann es schon geben, wenn sich die Entwickler dazu entschließen ein anzubieten. Bis dato trifft deine Aussage sicherlich zu. :wink:
Zitat von boardraiderDie kann es schon geben...
Nun ja, aber die Aussage
i understand that this bug matters to some people, but so do many other bugs.
fixing this bug is a non-trivial task. if it were a trivial task, we wouldn't
be having this discussion.
lässt kaum Hoffnung zu (und das war vor 5 Jahren) :wink:
lässt kaum Hoffnung zu
Auf das wollte ich hinaus. Möglich wäre ein Fix (daher kann es eine Lösung geben), aber selbiger befindet sich auf der Prioritätsliste am äußersten unteren Ende.
Zitat von boardraiderMöglich wäre ein Fix
Besser kann man die Untertreibung des Jahres nicht formulieren.
Wenn das die Untertreibung des Jahres sein soll, dann stellt sich für mich die Frage des Maßstabes :twisted:
Würde sich am Aufenthalt des Fehlers am Ende der Skala was ändern, wenn man den Eintrag ordentlich pusht und ebenfalls den Fehler meldet? Im Forum gibts sicher einige, die sowas mitmachen würden. Oder ist das unethisch?
Der Bug steht dort zu recht. Der Aufwand steht in keinem Verhältnis zum Gewinn. Wie oft hast du einen Crash? Und interessiert es dich dabei, ob der Browser-Cache erhalten bleibt? Das mag vor Jahren im Rahmen von geringen Bandbreiten noch eine kleine Relevanz gehabt haben, aber in Zeiten von 100 MBit? Selbst wenn sich ein Teil des deutschen Fx-Forums (zum Spaß oder welchen Grund hast du?) dazu entschließt für den Bug zu voten, würde mich das als Entwickler nicht wirklich jucken.
Weil ein Fix doch dafür nicht ausreicht und das Ziel nicht so einfach realisiert werden kann.
Der Fx muss die Handler für solche Situationen dem OS kundtun, die abgedeckten Module müssen die Daten für die Handler erreichbar gestalten und der Handler selbst muss mit den Daten sorgsamer umgehen, damit er selbst nicht das Schicksal des Moduls erleidet. Dies noch ohne Berücksichtigung der Daten, deren aktuelle Zustände und gewünschte Zustände.
Ist echt kein einfaches Unterfangen und da wägt man das Verhältnis Aufwand zu Nutzen schon sorgfältig ab.
Zitat von boardraider(zum Spaß oder welchen Grund hast du?)
Ausschließlich dieser Grund, ich hatte noch keinen Crash, der durch Firefox ausgelöst wurde, solange ich ihn nutze.
und das Ziel nicht so einfach realisiert werden kann
Hängt von den Ansprüchen an die Lösung ab. Den Index in gewissen Zeitabständen auf die Platte zu schreiben wäre ein Ansatz, der auch dort angesprochen wurde. Bei der sessionrestore.js wird vergleichbar verfahren.
Global Associate fragte Folgendes:
Nachdem ich gestern mal einen für mich seltenen Crash hatte, […] ist der Cache komplett gelöscht. Ist das eigentlich normal oder kann man was dagegen tun?[...]
Indem solche WWW-Objekte zur Effizienzsteigerung aus dem lokalen Proxy-Server (Cache) regelmässig in kurzen Abständen in eine separate Datei geschrieben werden. Idealerweise böten sich für diesen Zweck Programme an, welche die Historie-Datei des Firefoxes einzulesen vermögen, um diese dann jeweils inkrementell erneut abzulegen. Offengestanden kenne ich keines.
Auf Systemebene hingegen könnte - meinen Informationen nach - die regelmässige Auslagerung der places.sqlite (SQLite Format) über eine geschriebene „Snapshotfunktion“ (z.B. einer Batch-Datei) realisiert werden, welche dann wiederum regelmässig und zeitgesteuert über den Taskplaner zur Ausführung gebracht wird.
Oliver
O.T
Unter digital-forensischen Aspekten, bietet die „places.sqlite“ unter Firefox 3 teilweise effiziente Möglichkeiten zur Wiederaufbereitung von Objekten (Daten) und Operationen (Verfahren / Verbindungen), welche von einem bestimmten Ereignis betroffen sind – bzw. auch dem Zeitpunkt, zu dem das entsprechende Ereignis ursprünglich ausgelöst wurde.
