Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
Hallo Anton7, Ich habe das von Dir beschriebene Problem nochmal nachgestellt (Xubuntu 16.04, FreeFileSync 9.7 vom 12.1.2018). Bei mir klappte alles problemlos, sowohl der direkte Zugriff auf den alternativen FUSE-Pfad in /run/users/1000/gvfs/ als auch der Zugriff über eine symbolische Verknüpfung (Symlink) in meinem Heimverzeichnis. Könnte es sein, dass die Share zu dem Zeitpunkt, in dem Du den Zugriff mittels FreeFileSync versucht hast, noch gar nicht eingebunden war? Sollte das Problem bei Dir weiterhin auftreten, dann beschreibe bitte genau, wie Du vorgegangen bist. Gruß – Max-Ulrich
|
Anton7
Anmeldungsdatum: 11. Mai 2017
Beiträge: 60
|
Hallo Max-Ulrich, danke für die Antwort und das Prüfen! Das hat mich nochmal zum Ausprobieren animiert. Problem ist nun behoben:
Hatte FreeFileSync aus der Anwendungsverwaltung von Linux Mint 18. Was auch immer das war, es war nicht das richtige. Ist dort inzwischen auch verschwunden. Nach Deinstallation und kopieren FFS 9.7 für Ubuntu 16.04 von freefilesync.org läuft FFS wie erträumt und von Dir beschrieben. Alle die nun sagen, dass hätte nicht in dieses Forum gehört, dürfen mich nun verhauen. Sorry. Hatte meinen Ubuntu-Rechner aber zum Gegenprüfen leider nicht verfügbar. Gruß
Anton
|
nahitaji_msaada
Anmeldungsdatum: 30. Juni 2014
Beiträge: 554
Wohnort: Freising
|
Hallo Zusammen, da auch ich dieses Programm sehr schätze, habe ich etwas recherchiert um es unter 17.10 installieren zu können. Zuerst die aktuelle Version hier herunter laden: FreeFileSync: https://www.freefilesync.org/download.php Dann: tar xvzf ~/Downloads/FreeFileSync*.tar.gz -C /tmp/
sudo mv /tmp/FreeFileSync* /opt/FreeFileSync
sudo chown -R xxx:xxx /opt/FreeFileSync
sudo ln -s /opt/FreeFileSync/FreeFileSync /usr/local/bin/FreeFileSync Starten: FreeFileSync Funktioniert mit Budgie 17.10 ☺
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29067
Wohnort: WW
|
Hallo, thx - aber ist doch auch so im Wiki beschrieben, halt "nur" für 16.04 und 14.04. Gut, im Wiki wird der symbolische Link nicht angelegt - aber das muss ja jeder selber wissen. Gruß, noisefloor
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
Ich hätte den Artikel gerne für ca. 14 Tage in der Baustelle. Das Programm läuft zwar wie beschrieben auch in Ubuntu 20.04 (von Kellerkind_2009 getestet), doch seit der ursprünglichen Fassung des Artikels kamen noch einige Features dazu. Außerdem sollte die Konfiguration deutlicher und verständlicher erklärt werden. Gruß – Max-Ulrich
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29067
Wohnort: WW
|
Hallo, Baustelle ist eingerichtet. In dem Zuge kannst du bitte auch direkt alles entfernen, was zu Xenial gehört, auch das "xenial" aus der getestet-Vorlage. Gruß, noisefloor
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
In dem Zuge kannst du bitte auch direkt alles entfernen, was zu Xenial gehört, auch das "xenial" aus der getestet-Vorlage.
Das kann ich natürlich machen. Doch ich dachte, bis zum Rollout von Ubuntu 21.04 muss das drin bleiben(?): LTS = fünf Jahre Support… Gruß – Max-Ulrich
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29067
Wohnort: WW
|
Hallo,
Doch ich dachte, bis zum Rollout von Ubuntu 21.04 muss das drin bleiben(?): LTS = fünf Jahre Support…
Theoretisch ja, praktisch kann es aber jetzt schon entfernt werden, wenn Artikel übersarbeitet werden. Dann braucht man den Artikel nicht 2x anpacken. Gruß, noisefloor
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
Wieder zum Programm selbst: @nahitaji_msaada: Funktioniert mit Budgie 17.10 ☺
Das kann eigentlich nicht sein, zumindest nicht mit einer Version von FreeFileSync, die nicht als .deb-Paket installiert wurde. Es handelt sich um eine Eigenheit von manchen Programmen, die in einen beliebigen Ordner eigener Wahl oder auch z.B. auf einen USB-Stick installiert werden können. FreeFilesync muss den Pfad zum Ordner Bin innerhalb des Ordners, in dem sich die ausführbare Daten FreeFileSync befindet, kennen. Dieser wird mittels realpath aus dem Übergabeparameter 0 ermittelt, der immer den Aufruf-Befehl inclusive Pfad zu dem Ort, von dem aus der Aufruf erfolgt, enthält. Und das kann bei dieser Installation bzw. Aufruf nicht klappen. – Im Artikel werde ich auf dieses typische Problem von manchen "flexibel" oder portabel installierbaren Programmen eingehen. Bei früheren Versionen von FreeFileSync, die als deb-Paket angeboten und so immer am gleichen Ort fest installiert wurden, gab es das (leicht zu umgehnde) "Problemchen" noch nicht. Gruß – Max-Ulrich
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
Max-Ulrich_Farber schrieb: […] Das kann eigentlich nicht sein, zumindest nicht mit einer Version von FreeFileSync, die nicht als .deb-Paket installiert wurde. Es handelt sich um eine Eigenheit von manchen Programmen, die in einen beliebigen Ordner eigener Wahl oder auch z.B. auf einen USB-Stick installiert werden können. FreeFilesync muss den Pfad zum Ordner Bin innerhalb des Ordners, in dem sich die ausführbare Daten FreeFileSync befindet, kennen. Dieser wird mittels realpath aus dem Übergabeparameter 0 ermittelt, der immer den Aufruf-Befehl inclusive Pfad zu dem Ort, von dem aus der Aufruf erfolgt, enthält. Und das kann bei dieser Installation bzw. Aufruf nicht klappen. – Im Artikel werde ich auf dieses typische Problem von manchen "flexibel" oder portabel installierbaren Programmen eingehen.
Ein solches Verhalten sollte es eigentlich nicht geben. Ich kann mir hier zwei mögliche Ursachen vorstellen: Muss da Unterverzeichnis mit den ausführbaren Programmteilen Bin oder bin heißen? Unter Windows macht das keinen Unterschied, wohl aber bei unixoiden Betriebssystemen. Möglicherweise steckt da ein Programmierfehler in dem betriebssystem-übergreifendem Code. Das Programm realpath funktioniert unter Ubuntu 20.04 so wie man sich das vorstellt, auch bei Links. Das war aber nicht immer so und könnte zu einem von der Ubuntu-Version abhängigen Verhalten führen.
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
Muss da Unterverzeichnis mit den ausführbaren Programmteilen Bin oder bin heißen?
Es heißt tatsächlich Bin. Doch daran liegt es nicht. Soviel ich sehe, stimmt meine Erklärung des Sachverhalts schon, und sie stimmt auch mit einer Analyse im Linux-Mint-Forum überein: https://forums.linuxmint.com/viewtopic.php?t=325512 Dort werden die Symlinks allerdings zunächst als Ursache angenommen, doch an diesen liegt es nicht primär. Ich habe auch länger herumexperimentiert, bis mir der Sachverhalt klar wurde:
Dazu habe ich FreeFileSync in /opt/FreeFileSync installiert (bzw. entpackt) und das Executable FreeFileSync nach /usr/local/bin verlinkt, was (überprüft) in $PATH enthalten ist. So gut, ist ein übliches Verfahren, müsste eigentlich funktionieren… Das Programm realpath hat, im Terminal von Hand ausgeführt, bei mir stets korrekt funktioniert, auch bei Symlinks. Das heißt, der Pfad des aufgerufenen Programms wurde, auch über einen Symlink hinweg, immer korrekt ermittelt. realpath kann aber nicht den Pfad zu Programme ermitteln, die von einem anderen Ort aus (z.B. Heimverzeichnis) über die Variable $PATH aufgerufen werden. Es ergänzt dann den Programmnamen mit dem Pfad zum Ort, von dem aus der Aufruf erfolgt (z.B. Heimverzeichnis). Das Executable FreeFileSync ist in Wirklichleit nur eine Verzweigung zu je nach System verschiedenen Varianten des eigentlichen Programms im Ordner Bin (also /opt/FreeFileSync/Bin). Da sich die "Installation" von FreeFileSync aber an beliebiger Stelle befinden kann, kennt das Verzweigungsprogramm FreeFileSync den Pfad zum Ordner Bin zunächst nicht. Es ermittelt diesen (Frage"wo befinde ich mich?) durch interne Anwendung von realpath bzw. aus dem Übergabeparameter 0. Ob dies funktioniert, hängt nun davon ab, was dieser Parameter enthält. Das Verfahren funktioniert, wenn vor dem Aufruf ins betreffende Verzeichnis verzweigt wurde (hier /opt/FreeFile'Sync). Das ist trivial. Es funktioniert auch dann, wenn der Aufruf ohne Verzweigung ins betreffende Verzeichnis mit vollem Zugriffspfad erfolgt (der Weg für Starter in der GUI). Beim Aufruf über $PATH enthält der Parameter 0 die nötige Information jedoch nicht. Ich weiß nicht, wie sonst ein von einem anderen Ort aus ohne vollen Pfad über $PATH aufgerufenes Programm die Frage "wo befinde ich mich" beantworten könnte ( ❓ ).
Das Ganze ist zwar sehr irritierend ($PATH funktioniert scheinbar nicht), aber es ist kein Bug und leicht zu umgehen. Gruß – Max-Ulrich
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
kB schrieb: […] Das Programm realpath funktioniert unter Ubuntu 20.04 so wie man sich das vorstellt, auch bei Links. Das war aber nicht immer so und könnte zu einem von der Ubuntu-Version abhängigen Verhalten führen.
Ich habe es getestet: realpath aus coreutils Version 8.25 (wie bei Ubuntu 16.04) funktioniert richtig. Meine Erinnerung an Fehlfunktionen dieses Programms betrifft als nur noch ältere, heute nicht mehr relevante Versionen.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
Max-Ulrich_Farber schrieb: […] Beim Aufruf über $PATH enthält der Parameter 0 die nötige Information jedoch nicht.
Das widerspricht meiner Erfahrung. Beim Start eines Programms bzw. eines Skripts über PATH enthält der Parameter 0 den vollständigen absoluten Pfad zur ausführbaren Datei. Mein Testskript: $ cat ~/Skripte/realpath-test
#! /bin/bash -e
echo Ich bin $0.
realpath $0 Mein PATH: $ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/klaus/Skripte Test: $ realpath-test
Ich bin /home/klaus/Skripte/realpath-test.
/home/klaus/Skripte/realpath-test
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
Ich muss jetzt der Sache noch ein bisschen gründlicher nachgehen. Vielleicht sind wir also doch einem Bug in FreeFileSync auf der Spur. Ich stelle jetzt deshalb die Installation von FreeFileSync mit Deinem Dummy-Skript nach:
$ sudo cp ~/Skripte/realpath-test /opt/FreeFileSync/
[sudo] Passwort .....
$ sudo chmod a+x /opt/FreeFileSync/realpath-test
$ sudo ln -s /opt/FreeFileSync/realpath-test /usr/local/bin
$ realpath-test
Ich bin /usr/local/bin/realpath-test.
/opt/FreeFileSync/realpath-test
Tatsächlich funktioniert also alles wie es soll! Über $0 wird zwar der Pfad zum Symlink übermittelt, aber realpath findet damit den Pfad zur ausführbaren Datei. Damit müsste dann auch der Ordner Bin gefunden werden. Das müsste auch im wirklichen FreeFileSync funktionieren. Statt dessen erhält man die Fehlermeldung:
$ FreeFileSync
Cannot determine real path for "FreeFileSync".
Error code 2: No such file or directory [realpath]
Also wohl doch ein Bug in FreeFileSync! – Leider ist das Verzweigungsprogramm FreeFileSync kein einfaches Skript, da wäre der Fehler wohl schnell gefunden… Ich war also leider wieder zu schnell mit einer scheinbaren Erklärung. 😳 Gruß – Max-Ulrich EDIT: Wenn ich jedoch FreeFileSync mit dem vollen Zugriffspfad zum Symlink aufrufe, wird das Programm gestartet, allerdings mit einer seltsamen Fehlermeldung:
$ /usr/local/bin/FreeFileSync
(FreeFileSync_x86_64:30681): IBUS-WARNING **: 18:25:47.822: Unable to connect to ibus: Verbindung ist gescheitert: Verbindungsaufbau abgelehnt Ich möchte jetzt aber keine Jagd nach dem Bug unternehmen. Ich weise nur ganz kurz im Artikel auf diesen hin. Der Aufruf mit vollem Zugriffspfad funktioniert ja trotzdem immer.
|
Max-Ulrich_Farber
(Themenstarter)
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
Vorgestern habe ich den Maintainer von FreeFileSync (Zenju) angeschrieben, und heute (Sonntag Abend) habe ich schon eine gefixte Version 11.6 beta erhalten, die jetzt einwandfrei funktioniert. Das nenne ich Service! 👍 Danke auch an kB für den Nachweis, dass es sich wirklich um einen Fehler in FreeFileSync handelte. Ich hatte mich da getäuscht. Gruß – Max-Ulrich
|