immer schreibgeschützt öffnen

LibO Version 6.4.7.2 (x86)

Wie kann ich erzwingen, dass eine Datei für alle standardmäßig und ohne Abfrage schreibgeschützt geöffnet wird, sodass andere Personen die Datei noch bearbeiten und abspeichern können?

Die Datei liegt auf einem Netzlaufwerk und es arbeiten mehrere Personen damit. Meistens muss die Datei nur gelesen werden und nicht bearbeitet. Bearbeiten soll dennoch weiterhin möglich sein.

Ich habe versucht die Funktion “Datei → Eigenschaften → Sicherheit → Datei schreibgeschützt öffnen” zu verwenden. Die Datei geht dann auch für den ersten Anwender (A) ohne Nachfrage mit aktiviertem Schreibschutz auf. Über “Bearbeiten → Bearbeitungsmodus” kann er in den Schreibmodus gelangen. Also eigentlich genau das was ich suche.

ABER: Es wird trotzdem eine Lock-Datei erstellt und somit bekommt der nächste Anwender (B) einen Abfragedialog ob er schreibgeschützt arbeiten möchte oder eine Arbeitskopie öffnen. Das ist jedoch widersinnig weil die Datei ja sowieso nur schreibgeschützt geöffnet werden soll per o.g. Einstellung. Zudem kann Anwender B nicht in den Bearbeitungsmodus wechseln wenn er sich für schreibgeschützt entschieden hat. Die Arbeitskopie kann nicht unter dem gleichen Namen gespeichert werden (Kein Zugriff).

Dasselbe Verhalten beobachte ich wenn ich die Datei mit Kennwort speichere und den Haken bei “Datei schreibgeschützt öffnen” setze. Was kann ich tun damit nicht jeder beim öffnen der Datei eine Abfrage beantworten muss und jederzeit in den Bearbeitungsmodus wechseln kann solange noch kein anderer im Bearbeitungsmodus ist?

Die Datei liegt auf einem Netzlaufwerk und es arbeiten mehrere Personen damit

Wenn ich das mir überlege, hängt es am verwendeten Netzwerkfilesystem und den Fähigkeiten des Servers, ob Du Dein Ziel erreichen kannst. Mit Mitteln von LibreOffice alleine (und ich rede jetzt nicht von LibreOffice Online / CODE, sondern von lokalen LibreOffice Installationen) wird das, was Du dir vorstellst und wie ich das im Moment verstehe, nicht möglich sein. Ich sehe eigentlich nur die Chance, das File Locking von LibreOffice ganz zu deaktivieren und es dem Netzwerkprotokoll zu überlassen, ob geschrieben werden kann oder nicht.

Daher die Nachfrage: Welches Netzwerkprotokoll (SMB/CIFS, NFS) mit welchem Server implementiert (Windows native, Linux SAMBA, Linux NFS, Windows NFS,…) verwendest Du und auf welchen Betriebssystem laufen die Clients (ok x86 deutet auf Windows, wobei mich 32-bit ein wenig verwirrt)?


(Vielleicht hat aber auch jemand eine andere Idee)

Wir verwenden eine Netapp mit CIFS Protokoll. Die Freigaben werden vom Windows-Domänencontroller verteilt und mit Win10 Clients abgerufen. Manche User arbeiten auf einem Terminalserver.

Ich kann mir aber beim besten Willen nicht vorstellen, dass das Dateisystem hier mit reinspielt. Im Editor/Notepad kann ich Dateien ja auch beliebig oft öffnen. Das steuert doch die Anwendung ob sie einen lock auf die Datei setzt. Und LibreOffice bringt ja eigentlich auch alles mit, damit das funktionieren kann:

Wenn die Anwender diszipliniert immer den Bearbeitungsmodus rausnehmen wird auch die Lock-Datei entfernt und der nächste Anwender merkt gar nicht, dass noch jemand “in der Datei ist”. Das ganze müsste jetzt halt nur noch automatisch funktionieren. Und dafür bringt LibO ja die Funktion “schreibgeschützt öffnen” mit. Nur tut sie nicht was ich erwarte, sondern erstellt eben doch eine Lock-Datei. Ob die Datei dann auf Dateisystemebene gesperrt ist habe ich nicht geprüft, da nicht relevant.

Ich kann mir aber beim besten Willen nicht vorstellen, dass das Dateisystem hier mit reinspielt.

Dann schau dir mal die Lock Optionen eines SAMBA Servers (CIFS) an (Einen NetApp Filer nenn ich nicht mein Eigen, daher kann ich zu dessen CIFS Implementierung nichts sagen). Ich behaupte ja nicht dass es damit so geht, wie Du willst. Ich sage nur: Ich kann mir nicht vorstellen, dass Du das mit Mitteln, die LibreOffice heute implementiert hat, hinkriegst. Der Punkt ist hier ja offensichtlich folgender: Bevor LibreOffice den Inhalt einer Datei kennt - und damit die Einstellung “Read-Only öffnen” zur Kenntnis genommen hat, ist das Malheur (aus Deiner Sicht) passiert und die LibreOffice Lock-Datei bereits erzeugt. Wenn dem so ist, wovon ich ausgehe, dann ist die einzige Chance eine(n) Feature Request / Funktionsanfrage unter Bugzilla zu stellen, die in etwa lautet: “Entferne Lock Datei, wenn eine Datei per Einstellung Read-Only geöffnet wurde”.

Fortsetzung

Und ich habe noch ein wenig in Bugzilla gestöbert: Siehe da - tdf#137793 LibreOffice doesn’t remove the lock file after having opened a file and recognized that it has a read-only. Vielleicht kannst Du dich da einklinken, Deine Bedürfnisse mit einfließen lassen und im Zweifel die Implementierung beschleunigen. Vielleicht gibt es dort im Lauf der Diskussion auch einen Hinweis auf einen Workaround.

Danke für den Hinweis auf Bugzilla. Ich hatte schon befürchtet, dass es darauf hinausläuft.

“mit Mitteln, die LibreOffice heute implementiert hat, hinkriegst”
Aber das hab ich doch beschrieben. Manuell funktioniert das wunderbar. LibO KANN es.

LibO KANN es.

Sorry, aber das verstehe ich nicht. Du beschreibst lang und breit (und stellst eine entsprechende Frage), dass es gerade für Deinen speziellen Anwendungsfall nicht so funktioniert, wie du es haben willst und ich versuche zu erklären, warum nicht. Warum willst Du mich jetzt vom Gegenteil überzeugen? LibreOffice kann zur Zeit das Lock File nicht löschen, auch wenn es erkannt hat, dass eine Datei Read-Only geöffnet wurde. Und das nenne ich: Es hat derzeit keine Mittel an Board, so etwas zu tun.

Weil es nicht stimmt, dass LibO die Lock-Datei nicht entfernen kann. Du kannst es gerne selbst ausprobieren. Öffne eine Datei und nimm den Bearbeitungsmodus raus. (Shift+Strg+M).

Mir geht es um einen Weg, dies zu automatisieren.

… Seufz. Natürlich kannst Du ein Macro in jede Datei (evtl. Template) und jede LibreOffice Installation stecken, die das Lockfile entfernt. Ich habe nie behauptet dass das nicht geht. Ich habe behauptet, dass LibreOffice das (ergänzend: von sich aus) nicht macht, auch wenn es erkannt hat, dass eine Datei Read-Only geöffnet wurde. Ein Macro ist aber in meinen Augen eben kein Boardmittel, der deinen Prozess abbildet (Darunter würde ich eine Option ala *Don’t create lockfile on Read-Only" oder ein entsprechendes Default-Verhalten verstehen). Und wie Du zu recht formuliert hast, ist es nicht einsichtig, dass ein Read-Only geöffnetes File ein Lockfile hat, und man selber über ein Macro dafür sorgen muss, dass es verschwindet. Deswegen gibt es ja den Fehlerbericht tdf#137793.

Fortsetzung

Das folgende (simplifizierte) Macro, dem Ereignis “Ansicht wurde erzeugt” zugewiesen, lässt das Lockfile beim Öffnen der Datei verschwinden (Der UNO Befehl muss zweimal da sein, analog zu dem was man im UI machen muss - ist also kein Typo):

Sub ToggleEditMode
 
   dim oDoc as object
   dim oDisp as object
   dim pArgs(0) as new com.sun.star.beans.PropertyValue

   oDoc   = ThisComponent.CurrentController.Frame
   oDisp = createUnoService("com.sun.star.frame.DispatchHelper") 

   oDisp.executeDispatch(oDoc, ".uno:EditDoc", "", 0,pArgs())
   oDisp.executeDispatch(oDoc, ".uno:EditDoc", "", 0,pArgs())
      
End Sub

Das klappt zumindest bei mir unter:

Version: 7.0.4.2, Build ID: dcf040e67528d9187c66b2379df5ea4407429775
CPU threads: 8; OS: Linux 5.3; UI render: GL; VCL: kf5
Locale: de-DE (de_DE.UTF-8); UI: de-DE, Calc: threaded

hui, ich bin zwar kein Fan von Macros (und hab daher auch kaum Erfahrung damit) aber das hört sich ja tatsächlich nach einer Möglichkeit an. Werde ich auf jeden Fall mal ausprobieren. Ein natives Feature wäre mir zwar lieber aber da muss ich dann wohl Bugzilla bemühen. Vielen Dank erstmal.

Ein natives Feature wäre mir zwar lieber aber da muss ich dann wohl Bugzilla bemühen.

Wie bereits 2x geschrieben: Einen solchen Feature Request gibt es bereits.

Ja, weil du es schon 2x geschrieben hattest, habe ich zurückgemeldet, dass ich deinen Vorschlag mich in die Entwicklung einzubringen aufgreifen möchte.

Nicht missverstehen bitte - Ich wollte nur verhindern, das Du ein Duplikat erstellst, dass dann von den Entwicklern / QA-Leuten direkt wieder geschlossen wird. Mea culpa - hätte ich natürlich auch gleich so schreiben können.

Alles gut. Ich hab ja auch nicht explizit gesagt, dass ich mich in den von dir verlinkten Bug report einklinken möchte.