Mit meheren Profilen die selben Lesezeichen verwenden?

HT-Frogger

Hat schon mal jemand versucht mit mehreren Füxen (und auch mehreren Profilen) auf ein und dieselbe "places.sqlite" also die Lesezeichen zuzugreifen? Ich stelle es mir so vor: In einem der Profil liegt die wirkliche Datei, in allen anderen Profilen nur ein symbolischer Link.

Solange nur ein Fux offen ist, müßte es prinzipiell gehen, aber was passiet wenn mehrere offen sind und womöglich auch Änderungen schreiben wollen? Das passiert natürlich nicht gleichzeitig weil ja nur 1 User davor sitzt. Wenn nur etwas vergessen wird einzutragen ist es ja nicht schlimm, aber kann die Datei davon Schaden nehmen?

Wenn mein Texteditor eine Datei offen hat und sie wird von anderer Seite verändert, dann werde ich gefragt was denn nun gültig sein soll, aber was macht der Fux in solchem Fall?

Gruß Harry

EffPeh

Das wird so sicher nicht funktionieren. places.sqlite ist eine Datenbank und FF wird schon beim Start damit ein Problem haben, wenn er statt der Datenbank nur eine Verknüpfung vorfindet. Alleine schon aus Sicherheitsgründen sollte FF sich über die Verknüpfung beschweren. Im besten Fall ignoriert er die Verknüpfung und legt einfach eine neue places.sqlite an.

HT-Frogger

Ich habe mal folgenden Test gemacht:

1. FF beta geöffnet (dort liegt die Datei places.sqlite im Profilordner).
2. FF nightly geöffnet (dort ist ein Symlink zu der selben places.sqlite im beta-Profil).
3. In der beta ein neues Lesezeichen gespeichert.
4. Es war auch in der nightly ohne Neustart gleich darauf vorhanden!
5. Dieses Lesezeichen in der nightly gelöscht.
6. Es war in der beta jedoch immer noch vorhanden (scheinbar!).
7. Nach Neustart war es jedoch auch in der beta weg.

Angemeckert hat der Fux nichts. Aber ob das auf die Dauer gut ist, das ist fraglich. Datenbanken sind nicht so mein Fall. Aber ich haba ja Sicherungskopien, da kann man ja mal "spielen"...

Gruß Harry

EffPeh

Ochja. Hätte ich jetzt nicht gedacht.
Oder hat die nightly evtl. eine neue places.sqlite angelegt und es ist nur zwischen den FFs gesynct worden?
Auf jeden Fall ein interessantes Experiment.

HT-Frogger

Das es grundsätzlich gehen muß war mir an sich klar. Symlinks sind bei Linux zu hunderten vorhanden, das ist allgemein üblich. Aber ob das mit dem gleichzeitigen öffnen gut ist, das weiß ich nicht. Aber Datenbanken sind doch an sich multi-user-fähig, oder sehe ich das falsch? Wenn von FF nichts geschrieben wird, z.B. bei der userChrome.css und ähnlichem, ist es ohnehin kein Problem die mit Symlinks zu "verteilen".

Sogar die Chronik des 1. Fux ist im 2. geöffneten Fux dann vorhanden, die lösche ich aber beim beenden immer. Deshalb stört es mich nicht, wenn da etwas "abhanden" kommen sollte.

Ach ja: Nein, er hat keine neue places.sqlite angelegt.

Gruß Harry

EffPeh

Grundsätzlich geht das auch bei Windows. Und natürlich können im Normalfall mehrere User/Programme auf eine Datenbank zugreifen. Ich hätte aber in diesem Fall gedacht, das es da bei FF Einschränkungen und Sicherheitsvorkehrungen gibt. Aber okay, dann ist das halt so. Auf jeden Fall gut zu wissen. :klasse:

clio

Zitat von HT-Frogger

Nein, er hat keine neue places.sqlite angelegt.

Kann auch nicht, der Name ist schon vergeben.
Wie verhält sich denn ein Link auf die prefs.js mit einer Änderung im jeweils anderen Profil? Müßte aber genauso funktionieren.
Ich habe keinen zweiten Fux, sonst würde ich das mal testen.

HT-Frogger

Die "prefs.js" wird doch automatisch erstellt und soll doch gar nicht manuell bearbeitet werden, oder sehe ich da etwas falsch? Die "user.js" kann man so verteilen, das habe ich auch gemacht. An sich kann man problemlos alles mit Softlinks verteilen was "von Hand" mit Inhalt versorgt wird und von den verschiedenen Füxen auch verstanden wird.

Gruß Harry

clio

Wenn man will, kann man die prefs.js durchaus manuell bearbeiten, das mache ich schon ab und zu. Man sieht ja auf einen Blick auch die Einstellungen aus about:config, aber man sollte auch im Hinterkopf behalten, daß diese Datei verändert werden kann. Mit einem Kopieren nach prefs.js-bak kann man mehrere Varianten vorhalten, ohne erst wieder Änderungen vornehmen zu müssen.
Wenn ich jegliche Änderungen ausschließen will, entziehe ich der Datei die Schreibrechte.
Kann man alles machen, man muß nur wissen, was man tut.

HT-Frogger

Sören hat mal folgendes geschrieben: "Die Datei prefs.js brauchst du gar nicht anzurühren, das ist eine generierte Datei. In dieser speichert Firefox geänderte Einstellungen."

In der prefs.js steht auch am Anfang:
/* Do not edit this file.
*
* If you make changes to this file while the application is running,
* the changes will be overwritten when the application exits.
*
* To make a manual change to preferences, you can visit the URL about:config
*/

Ich verstehe das so, da hat man nichts zu suchen, außer mal nachschauen was wirklich eingetellt ist.
Widerspenstige Einstellungen die gerne mal "verloren" gehen trage ich in der user.js ein, dann sind sie auf jeden Fall gültig.

Gruß Harry

Sören Hentzschel

Und vor diesem Hintergrund klingt:

> Wenn ich jegliche Änderungen ausschließen will, entziehe ich der Datei die Schreibrechte.

… nach einer furchtbar schlechten Idee. Abgesehen davon, dass man grundsätzlich nicht an den Schreibrechten von Dateien spielen soll, welche von Firefox oder irgendeiner anderen Anwendung genutzt werden. Damit betritt man den Bereich nicht unterstützter und ungetesteter Szenarien, was zu ernsthaften Problemen bis hin zu Abstürzen führen kann, weil eine Anwendung nun einmal gewisse Annahmen trifft und man selbst nicht die Annahme treffen kann, dass jeder erdenkliche Weg, der aus Entwickler-Sicht gar nicht existieren dürfte, code-seitig abgesichert ist.

clio

Ja, schon richtig. Daher hatte ich auch geschrieben: Man sollte schon wissen, was man tut....
...und das solche Aktionen nichts für Anfänger sind, versteht sich von selbst.

Sören Hentzschel

Das hat überhaupt nichts mit Anfänger oder Nicht-Anfänger zu tun, oder mit dem Wissen oder Nicht-Wissen, was man tut. Es ist einfach ein falscher Weg, weil man damit undefiniertes Verhalten auslöst.