Date: prev next · Thread: first prev next last
2019 Archives by date, by thread · List index


Hallo Peter,

Bisher gibt es keinerlei Reaktion? Wie soll ich das verstehen? Ist
das Problem schlecht beschrieben, zu kompliziert oder sollte es
wirklich niemand geben, der dazu etwas sagen kann? Mich bewegt es
schon längere Zeit und ich würde es gern "mal vom Tisch" kriegen.

Ich kann erst einmal bestätigen, dass ich das gleiche Problem hätte,
wenn ich die Funktion nutzen würde, was ich aber nur für diese Test das
erste mal getan habe.

Aus deinen Info schließe ich, dass du sowohl unter Windows, als auch
unter Linux die Dateien der betreffenden Freigabe über einen direkten
(UNC-)Pfad ansprichst, also unter:

        Windows: \\server\freigabe\...
        Linux: smb://server/freigabe/...


Du schreibst ja, dass der Link im Dokument als "smb://..." gespeichert
wäre.

Leider heißt das ja nicht, das Linux und Windows hier auf die gleiche
Nomenklatur zurück greifen, sondern nur, dass sich die
LibreOffice-Macher für die Speicherung des Netzwerkpfades auf diese
Nomenklatur geeinigt haben... Das macht ja auch Sinn, da man die gleiche
Schreibweise für diverse andere Protokolle verwenden kann: ftp://... ,
http://...

Bei der Übergabe an das Windows-System, das mit dieser Angabe so gar
nicht anfangen kann, wird diese Angabe wohl in die dort übliche
UNC-Pfadangabe (\\...\...\...) gewandelt, während es bei Linux direkt
an den Desktop übergeben wird.

Unter Linux hingegen ist das SMB-Protokoll ja nicht nativ eingebaut, so
dass der Desktop entsprechende "Helfer" bemühen muss. Hier scheint dann
aber der Hund begraben zu sein:

Genau wie bei dir, bekomme ich Problemlos einen Link z.B. zu einer
Überschrift eines Dokumentes auf meinem NAS nur dann eingerichtet, wenn
ich den kompletten Pfad zum Dokument manuell vorgebe (hier:
smb://192.168.3.12/public/Test.odt).

Wenn ich hingegen mit dem sich öffnenden Dateiauswahlfenster zu der
Datei "navigiere", so scheitere ich! Selbst wenn ich die Eingabe per
Textzeile einschalte und den Pfad bis 

        smb://192.168.3.12/

oder gar bis

        smb://192.168.3.12/public

vorgebe, bekomme ich eine Fehlermeldung, das dies kein Ordner wäre und
kann auch nicht weiter navigieren.

Das ganze auf einem Laptop mit xfce unter Ubuntu.

So wie es ausschaut, gibt es da ein Kommunikationsproblem zwischen LO
und dem Desktop, so dass LO keine als gültig interpretierbare Angabe
zum Dateipfad zurück geliefert bekommt.

Wenn man das häufiger braucht, ist der Fehler natürlich lästig.

Ich würde dir empfehlen wollen, den Netzwerkpfad durch das "Mounten" der
Freigabe zu vermeiden. So würdest du einfach zu einem Dokument
innerhalb des Dateibaums verlinken und das "smb://" als
Protokollangabe könnte entfallen. Aber dann hast du ein Problem bei den
Windows-Rechnern, bei denen das "Mounten" ja nur als "Netzlaufwerk" mit
"Laufwerksbuchstaben" vorgesehen ist. Damit bekommt man schwerlich
einen Dateipfad, der sowohl unter Linux als auch unter Windows
identisch ist...

Gruß,
Michael 
-- 
    ____        
   / / / / /__/      Michael Höhne /
  /   / / /  /  mih-hoehne@web.de /
 ________________________________/


-- 
Liste abmelden mit E-Mail an: users+unsubscribe@de.libreoffice.org
Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Datenschutzerklärung: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.