amiba
Anmeldungsdatum: 22. Januar 2008
Beiträge: 126
|
Hi, ich habe die Funktion autofs in verbindung mit sshfs bei mir im Einsatz. Anfangs hielt ich den Timeout sehr kurz, t<6s, was ich dann geändert habe. Jetzt ist er auf 45s eingestellt und immer noch hab ich manches mal Probleme. So wird zum Bsp. die Verbindung wärend dem Betrachten eines Direktories zurück gesetzt. Wieso kann automount nicht feststellen, daß gerade ein Programm auf Daten zugreift und diese betrachtet. Es ist ja sonst auch so, daß man so lange man per cd in einem Direktory steht diese nicht einfach (termialfenster) man dieses nicht ohne weiteres unmounten kann. In der Regel erhält man eine Meldung wie Laufwerk bussy oder so. Hier hingegen jedoch befindet man sich plötzlich wieder im Mountdir obwohl mal davor noch in einem Subdirektory des selbigen war. (Normales Dateimanager Fenster) Weiß jemand ob es da einen Weg gibt der sicher ist oder muß ich mir ein Tool schreiben, daß dies überwacht? Vielleicht ein flag, daß dies dann managed?
|
MPW
Anmeldungsdatum: 4. Januar 2009
Beiträge: 3729
|
Hallo, über was für eine Verbindung verwendest du denn sshfs? WLAN/Internet/GSM? Innerhalb des LANs müsste das ein- und ausmounten so schnell gehen, dass du es kaum bemerkst. Mach mal einen Test: Statt autofs zu nutzen, mounte mal manuell: sshfs Nutzer@server-ip-oder-domain:/pfad/zur/freigabe /lokaler/Pfad Wenn es dann stabil ist, liegt es an autofs, sonst an der Netzwerkanbindung. Grüße
MPW
|
amiba
(Themenstarter)
Anmeldungsdatum: 22. Januar 2008
Beiträge: 126
|
Es ist so, daß ich es von überall her nutze und das auch in fremden Netzen, weshalb ich das sshfs ganz gern benütze, weil dann zumindest die Datenübertagung nicht im Klartext erfolgt. Die Daten generell zu verschlüsseln lohnt sich für mich nicht und macht höchstens irgend wann dann Ärger. Es ist kein Verbindungsabbruch wegen der ssh Verbindung, weil ich habe das schon getestet. Ein offenes terminalfenster zum selbigen ssh-Server bleibt on. Es ist ja auch nicht so, daß ich den Ort nicht mehr erreichen kann, sondern nur so, daß ich beim Suchen in einem Größeren Ordner schon mal plötzlich wieder den Einstiegsordner vor mir habe. Klicke ich den dann an, bin ich wieder auf dem System in unterverzeichnissen. Ist nur lästig, wenn man dann eben dort etwas Sucht die häfte aller Files schon durch hat und plötzlich wieder voll raus ist
|
MPW
Anmeldungsdatum: 4. Januar 2009
Beiträge: 3729
|
amiba schrieb: [...] Es ist kein Verbindungsabbruch wegen der ssh Verbindung, weil ich habe das schon getestet. Ein offenes terminalfenster zum selbigen ssh-Server bleibt on.
Das ist nicht dein Ernst? Eine SSH-Verbindung läuft auch über ein 56K-Modem, wenn es sein muss. SSHfs hat ganz andere Anforderungen an den Durchsatz der Leitung! Teste obigen Befehl! Bei welchem Verbindungen tritt das Problem denn überhaupt auf? Ich tippe Mal schwer darauf, bei Verbindungen von unterwegs, nicht unbedingt von daheim.
Es ist ja auch nicht so, daß ich den Ort nicht mehr erreichen kann, sondern nur so, daß ich beim Suchen in einem Größeren Ordner schon mal plötzlich wieder den Einstiegsordner vor mir habe. Klicke ich den dann an, bin ich wieder auf dem System in unterverzeichnissen. Ist nur lästig, wenn man dann eben dort etwas Sucht die häfte aller Files schon durch hat und plötzlich wieder voll raus ist
Das könnte schon von Verbindungsabbrüchen und umounts kommmen.
|
amiba
(Themenstarter)
Anmeldungsdatum: 22. Januar 2008
Beiträge: 126
|
Ich kann mit Sicherheit sagen, daß es von autofs kommt, weil ich habe bevor ich autofs benutzt habe ein Skript genutzt, daß mir immer mit dem Verbindungsaufbau zum wlan dieses Laufwerk gemounted hat. Da kam es nicht zu solchen komischen Wandlungen. Vor allem ist die Verbindung da dann ja nicht weg, sondern es wird nur etwas zurück gesetzt. Die von Hand gemachte Verbindung hat vielleicht mal bei irgend welchen Netzproblemen angefangen Schwierigkeiten zu bekommen und seit dem in Ubuntu etwas am Netwerkmanager geändert wurde, so daß jetzt bei Festnetzverbindungen die Kiste nicht mehr ins zuletzt benutzte Netz geht sondern in irgend eines der Netze mit denen sie sich automatisch verbinden soll, gibt es ab und zu Schwierigkeiten aber das ist was anderes. Das kann ich ausschließen, wenn ich nur ein wlan gerade mal nutze, keine Radioabbrüche habe, weil ich selbst noch Nachrichten lese oder sonst was mache. Ist auch nicht so, daß der Abbruch kommt wenn ich laufend neu zugreife. Diese Veränderung kommt genau mit dem Timeout. Hatte ihn zuerst auf 3 Sekunden, da ich eine Verbindung zu meiner Platte eigentlich nur haben wollte, wenn sie genutzt wird. Davor war ich ja laufend verbunden und das hat geklappt. Mir war es nur sympathischer nicht andauernd verbunden zu sein, wenn ich dieses Laufwerk nicht benutze. Daß autofs nicht bemerkt, wenn ich in einem Direktory etwas Suche und eben, weil ich den Filenamen nicht genau kenne alle Filenamen der Reihe nach lese, dies dann nicht in den 45 Sekunden, die ich mir jetzt eingestellt habe schaffe ist mir völlig klar. Ich kann mir auch 10 Minuten einstellen, dann kommt es seltener vor, doch will ich eigentlich haben, daß so lange ich mich in einem Direktory oder auf der Platte selbst befinde diese nicht zurückgesetzt wird. Jetzt weiß ich jedoch nicht wie ich das erreiche, weil irgendwie autofs nicht merkt wenn ich ein Direktory auf dem Entsprechenden Medium offen habe. Mir wäre also gedient, wenn irgend wie die Meldung des geöffneten Direktories oder so an autofs gereicht würde. Vermutlich ist es so, daß autofs nur nach lsof sieht und da kann man vermutlich nicht mehr sehen, wenn ich ein Direktory zwar gelesen wurde und man sich auch in diesem Befindet, es jedoch nicht mehr als File geöffnet ist. Somit der Zugriff ja nicht mehr andauert, obwohl man sich in dem Direktory befindet. Ich habs gerade mal genauer studiert, wenn ich per Terminal in dem Directory bin, dann bleibt das Laufwerk dauergemounted. Wenn ich im Filemanager von Gnome bin, dann setzt sich das zurück, weil der Manager öffnet das zu lesende Direktory, liest seinen Inhalt und obwohl er sich noch dort befindet, schließt er den Zugriff und somit ist über lsof nicht ein Zugriff auf dieses Direktory zu bemerken. Wenn ich dann dort was suche bricht halt mitten drin die Verbindung ab. Das merkt man daran, daß der Filemanager sich auf das Mountdirektory zurücksetzt, an dem das Laufwerk eingehängt wird. Dieses Verhalten ist schon blöd, weil auch mit einer längeren Zeiteinstellung wird der Fehler nur seltener, jedoch nicht behoben und wie ich den Filemanager dazu bekomme, daß er laufend nachläd, wenn die Seite doch schon geladen ist, vor allem nur speziell bei Direktories in autofs mounts weiß ich nicht. Wäre aber eine Option. Die andere Option wäre, wenn der Filemanager bevor er sich zurücksetzt einfach nach einer Mitteilung, daß sein Direktory sich gerade unmounted versuchen würde erst mal, bevor er sich zurücksetzt noch mals den Inhalt des selbigen zu lesen. Dann würde es automatisch neu gemounted und wäre immer noch für den Benutzer da. Zwar keine schöne Lösung, wenn es laufend remounted wird aber geht irgend wie auch. Der Filemanager könnte auch laufend das Direktory touchen - so alle automount - 1 oder 2 Sekunden, dann würde das einen Zugriff generieren, der von autofs bemerkt wird und es bleibt gemounted. Wäre ja nicht mal verkehrt, wenn das Direktory noch offen ist, es als gerade benutzt zu markieren. Allerdings sind das alles Lösungen um das Problem herum. Besser wäre, wenn autofs bemerken würde, daß ein Programm darüber informiert werden muß, daß es gerade einen unmount gibt und statt dies dann darüber zu informieren, daß hier ein unmount stattfindet wäre es sinnvoll den zu unterlassen. So wäre es in meinen Augen richtig, weil ich glaube der Filemanager bekommt die Mitteilung, daß das Filesystem einen unmount erfährt und setzt sich somit auf das niedrigste im Ast befindliche Direktory. Was aus sicht des Filemanagers vollkommen richtig ist und Abstürze vermeidet. Wenn jedoch die Meldung für das umount einfach an alle geht, dann kann autofs sicher nicht wissen, daß jemand informiert werden mußte und darauf eine Reaktion erfolgt. Somit würde klar sein, daß man sich für den Speziellen Fall eine andere Lösung ausdenken muß. Beim Filezugriff funktioniert es zumindest ordentlich, weil das Speiern eines Files in ein Unterverzeichnis erfolgt immer, sofern das Laufwerk erreichbar ist ordnungsgemäß. Mit einfachem mounten hat es funktioniert und der Fehler tritt überall auf in jedem Netzwerk, egal ob ich 200Mbit/s oder nur 10kbit/s zum Netz habe.
Er tritt immer mit dem Timeout auf. Wenn ich den Timeout raus nehme, dann hat autofs fast keine Funktion mehr und wenn ich ihn zu lange setze, bleibt das Laufwerk einfach zu lange gemounted, was ich ja mit dem autofs umgehen wollte. Es nimmt dann autofs den Grund seiner Benutzung. in einem Versuch von mir das zu überwachen sah es so aus: so lange ich per bash in einem Direktory des Laufwerkes verweile, ist dieses geöffnet durch bash. (lsof | grep "mountname") ergibt das gerade von bash geöffnete Verzeichnis. So lange ich dieses so öffne, bleibt das Filesystem gemounted. Der Filemanager, der zugleich auf irgend einem Verzeichnis dieses Astes war bleibt dort.
Beende ich den Zugriff über bash und verlasse das Verzeichnis wieder, so daß ich nur noch mit dem Filemanager von Gnome zugreife, dann setz sich nach einer Zeit die durch das Timeout definiert wird der Filemanager zurück auf den Einhängepunkt. Was ja das Problem ist, daß ich angehen möchte.
|
MPW
Anmeldungsdatum: 4. Januar 2009
Beiträge: 3729
|
amiba schrieb: [...] Besser wäre, wenn autofs bemerken würde, daß ein Programm darüber informiert werden muß, daß es gerade einen unmount gibt und statt dies dann darüber zu informieren, daß hier ein unmount stattfindet wäre es sinnvoll den zu unterlassen.
Nah so ist es doch auch. Linux merkt eigentlich immer, wenn noch ein Programm auf eine gemountete Partition zugreift. Alleine schon, dass ein Ordner darin geöffnet ist, reicht in der Regel aus. Zumindest im Terminal, nautilus ist da etwas großzügiger und wechselt dann selbstständig in einen anderen. Guck Mal, ob du Logdateien findest, da ist irgendwas nicht ganz richtig bei dir. Hast du jetzt den Gegenversuch mitsshfs gemacht oder nur getextet? Was früher Mal war oder wie auch immer, interessiert hier nicht.
|
amiba
(Themenstarter)
Anmeldungsdatum: 22. Januar 2008
Beiträge: 126
|
klar hab ich das gemacht und zwar bevor ich autofs benutzt habe aber damit du beruhigt bist, ich habs auch gerade eben wieder versucht und es hat sich seit voriger Woche nichts geändert. Was vielleicht auffallen sollte ist, daß die Timeout Zeit von autofs wohl kaum Einfluß auf die im Filemanager geöffneten Files haben sollte. Wenn man es in einem Terminal macht hab ich ja schon geschrieben, daß es funktioniert. Allerdings wird ein vom Terminal geöffneter Pfad als Filediskriptor nicht geschlossen, weshalb man per lsof dann den Eintrag mit dem Mountkey immer findet. Wenn ich selbiges vom Filemanager aus mache dann liest der wohl das Direktory aus aber sobald er es gelesen hat wird der Discriptor geschlossen.
|
MPW
Anmeldungsdatum: 4. Januar 2009
Beiträge: 3729
|
Öffne Mal ein Terminal und navigiere per CD in der autofs-gemounteten Ordner und lass es denn geöffnet. Wenn das klappt, gibt es einen Bug im Zusammenspiel des Dateimanagers und autofs.
|
amiba
(Themenstarter)
Anmeldungsdatum: 22. Januar 2008
Beiträge: 126
|
Von was hab ich die ganze Zeit geredet. Ich habe doch beschrieben, daß es funktioniert, wenn man von bash aus in einem Ordner ist. Allerdings habe ich auch beschrieben, was da gewissermaßen anders läuft, weil bash ein Verzeichnis, wenn man in ihm ist nicht schließt. Somit ist der lsof output von einem Terminalzugriff nicht leer, weil ein File dauerhaft auf dem betroffenen Filesystem geöffnet ist. daß es sich um ein bug dreht oder eine Fehleinstellung ist mir klar. Nur wenn es eine Fehleinstellung ist, so daß man vielleicht autofs mitteilen kann, wie es solche Fehler umgeht oder jedoch dem Filemanager eine Modifikation verpaßt, falls autofs aktiv ist. Wobei das letztere in meinen Augen unsauber ist obwohl es funktioniert. Wenn ich mal viel Zeit habe lese ich mir vielleicht den Sourcecode dazu durch, weil als aller erstes müßte man ergründen wie der Filemanager von der Änderung erfährt. Sollte er eine direkte Nachricht erhalten, dann hätte dies autofs checken können. Wenn er jedoch selbst das System scannt und dabei den Fehler macht, den übrigens andere Programme auch machen, weil ein mit autofs gemounteter Inhalt bei einem Computerscann vom Internet aus nicht unbedingt auftaucht, dann wäre es nur mit der Modifikation des Filemanagers möglich. Wie geht man nun weiter vor, wenn es ein Bug ist?
|
MPW
Anmeldungsdatum: 4. Januar 2009
Beiträge: 3729
|
amiba schrieb: Von was hab ich die ganze Zeit geredet. Ich habe doch beschrieben, daß es funktioniert, wenn man von bash aus in einem Ordner ist.
Entschuldige bitte, mea culpa. Aber ich hab schon Kurzgeschichten gelesen, die kürzer waren als dein Post vom 08.02. 15:23. Ich hatte dich bereits darauf hingewiesen, dass das vermutlich sogar absichtlich im Filemanager so implementiert ist, damit man Laufwerke aushängen kann, während sie noch geöffnet sind. Dann wechselt er nämlich den Ordner. Ich denke du mischt hier auch zwei Nutzercharakteristiken: Entweder das Terminal benutzen und eben das klassische autofs, oder die Freigabe in der fstab eintragen und dann mit einem Klick über den Filemanager mounten. (Das geht dann ja ohne root.) Autofs verträgt sich wohl nicht so mit modernen grafischen Dateibrowsern. Ich denke das Problem ist diagnostiziert. Entweder den Filemanager patchen (Respekt, wenn du das kannst und die Zeit hast) oder die Nutzungsgewohnheiten so umstellen, wie es von den Maintainern beider Softwares gedacht ist.
|
amiba
(Themenstarter)
Anmeldungsdatum: 22. Januar 2008
Beiträge: 126
|
Die dauermount Lösung hatte ich vor automount. Warum will ich automount nutzen, weil ich dann nicht laufend verbunden bin und nicht laufend die Verbindung steht, falls ich vergesse das Laufwerk wieder auszuwerfen. Aktuell suche ich nicht mehr ohne find oder grep - also halt kaum noch mit dem Nautilus Teil. Nur die Automount Funktion ist damit in Bezug auf irgend was mal Optisch im Nautilus suchen obsolate. Wobei ich vermute, daß Nautilus vom automount Job informiert wird, wenn der etwas auswirft oder mounted. Sollte das so sein, könnte Nautilus immer wenn der Rauswurf kommt das Fenster refreshen und den Fensterinhalt somit schützen.
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
Ich möchte nicht behaupten, dass ich etwa eine zufriedenstellende Lösung mit autofs hätte. Doch in den meisten Fällen kann man statt autofs auch die standardmäßig vorhandene automount-Funktion von systemd verwenden, die sehr (absolut?) zuverlässig funktioniert. Man kann sie ganz einfach durch die entsprechenden mount-Optionen in fstab (Abschnitt „Automount-mit-systemd“) einrichten. – Oh pardon, Du verwendest ja noch Ubuntu 14.04. Ob das da schon geht, weiß ich nicht. Eventuell müsste man da vielleicht 'was nachinstallieren (?), und dann wird es komplizierter. Gruß – Max-Ulrich
|
amiba
(Themenstarter)
Anmeldungsdatum: 22. Januar 2008
Beiträge: 126
|
das mit dem 14.4 ist Geschichte. ist jetz 16.04 und ich verwende durchaus den fstab für einen automount. Allerdings nicht für diese Anwendung, weil so wie ich das bisher erlebt habe, der Automount im fstab dafür sorgt, daß ein Laufwerk sobald es da ist gemounted wird. Wenn jedoch das irgend wo im Netz ist, will ich überhaupt nicht, daß es gemountet wird außer jemand muß explizit darauf zugreifen. Daher auch autofs, denn das löst genau dieses Problem. Fürs suchen in Ordnern verwende ich halt inzwischen den Nautilus nicht mehr, weil es müßig ist, wenn man sich da in irgend einen Unterordner geklickt hat und nicht gleich findet was man sucht, dann jedoch die Verbindung zurück gesetzt wird. Hab mit inline keine Probleme und man muß ja nur in irgend einem Ast des Systems sein damit es nicht zum unmounten kommt. Wäre nur super gewesen, wenn die Programmierer das vielleicht berücksichtigt hätten, denn dann würde es komfortabel und gut sein.
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
Das mit Ubuntu 16.04 ist schon 'mal gut. ☺ der Automount im fstab dafür sorgt, daß ein Laufwerk sobald es da ist gemounted wird.
Da hast Du mich falsch verstanden. Bei einem fstab-Eintrag ohne besondere Parameter ist das natürlich so. Aber das Besondere an systemd ist eben, dass es auch die Möglichkeit bietet, wie bei Autofs die Freigaben erst beim Zugriff automatisch einzuhängen und bei längerem Nichtgebrauch wieder automatisch auszuhängen. Und das ist nicht nur über die Konfigurations-Datei von systemd, sondern eben auch ganz einfach über besondere Mount-Parameter in fstab möglich. Diese sind hier ganz kurz (und leider etwas unauffällig) beschrieben. Das klappt einwandfrei. Probier's mal. Gruß – Max-Ulrich
|
amiba
(Themenstarter)
Anmeldungsdatum: 22. Januar 2008
Beiträge: 126
|
Ok, das war mir neu, werde ich jedoch sehr bald testen, denn wenn es besser funktioniert als autofs, dann stell ich das einfach um. Wenn es nach mir geht wird aus 60s dann 15s, weil es kann wegen mir immer wieder neu gemountet werden, wenn ein Zugriff erfolgt, weil im allgemeinen entweder laufend zugegriffen wird oder kaum, und da ist selbst 60s über viel Zeit.
Gerade eben hat es nicht so funktioniert - denke aber das könnte auch am Umlaut in dem Filepath liegen, denn gemounted wurde er, ich konnte ihn lediglich nicht mal direkt unmounten (von nautilus aus, nach dem der Path die ganze Zeit gemounted blieb, obwohl ich das ja genau nicht haben wollte. Also wenn ich systemd verwende, dann gibt es ein Problem mit Umlauten, weshalb vermutlich das unmounten nicht klappt und selbst wenn man im Nautilus auf ausklinken klickt gibt es die Fehlermeldung, daß der Pfad ".../Büro/..." Allerdings wird das ü komisch ersetzt, nicht existiert. Somit bleibt es gemounted. Gerade hab ich mal wieder getestet, wie das autofs funktioniert und dabei ist mir etwas aufgefallen, das bislang noch nicht da war. In dem Autofs Ordner sind außer dem Ordner für das Büro noch andere Fernlaufwerke von mir enthalten. Wenn ich im Nautilus auf einem Ordner stehe und dort etwas suche der ein Unterordner des speziell betrachteten Pfades ist, was ich gerade gemacht habe und - nun ich hab in autofs eben 150s drin, damit ich nicht laufend bei geringeren Dingen durch automatische Beendungen gestört werde, dann wird nach Ablauf der Zeit plötzlich der Ordner in dem ich war geschlossen und Nautilus holt inzwischen den übergeordneten Ordner ("..") ins Fenster. Pop und man ist einfach eine Ebene höher. Wartet man dann weiter, passiert dies wieder, bis man im Stammordner ist in dem alle solchen autofs Laufwerke stehen. In dem Moment wo der Ordner auf geht, werden dann alle Verbindungen, die dort sind aktiv und gemounted. Wartet man noch etwas, ist man in dieser Ebene und alles ist nicht mehr gemounted. Das deutet darauf hin, daß sich jemand die Mühe gemacht hat Nautilus zu integrieren und das lediglich statt dem aktiven Direktory, auf das darüber liegende gesprungen wird. Also irgend wo im Script ein ganz kleiner Fehler aber damit eben doch ein Schritt in die Richtung dieses Problem zu lösen. Was die Idee betrifft, es könnte am sshfs liegen - nun ich nutze das aus langsamen Netzwerken aus schnelleren (bis 100Mbit/s) aus ultraschnellen (>100Mbit/s) und über GSM, UMTS, LTE, weil ich nutze es wo immer ich mich gerade befinde und ich habe dieses Laufwerk umgehostet von Strato, weil Strato keine Kompression anbietet, und ich die 25 Minütige Wartezeit bei schlechten Verbindungen mit nur 2k nicht vertragen habe - dafür jedoch bei Kompression in kauf nehme, daß es bei ultraschnellen Verbindungen nahezu 6* so lange braucht, weil die Kompression diese Zeit frißt und irgend wann das uploadlimit vom Host erreicht wird. Es hat mich aktuell noch nicht so sehr gestört, daß ich ein Script geschrieben hätte, daß die Kompression ein/aus schaltet je nach Verbindungsgeschwindigkeit, weil das wäre dann noch ein Itüpfelchen zum ganzen. Was das sshfs betrifft, so kann ich definitiv deutlich sagen, daß es funktioniert, weil ich per Terminal immer auf dem Laufwerk bleiben kann und weil ich genau weiß wie ich das feststellen kann. Ich hab das Laufwerk früher von Hand gemounted. Heute der Einfachheit eben per autofs. Die Verbindung klappt praktisch immer und da ich das selbst hoste weiß ich, daß es funktioniert. Wenn es mal nicht tut, dann kann ich das sehr schnell selbst feststellen und erörtern was nicht geht. Nur der Fehler, der in Nautilus passiert hat sich nun wohl geändert aber man kann sehen, daß jemand daran gearbeitet hat. Wieso es jetzt immer ein Direktory nach oben springt statt das aktive zu refreshen ist wohl eher ein Fehler beim Index. Also vielleicht ein Bug aber immerhin nur eines, daß man bestimmt umgehen kann. Früher sprang Nautilus dann immer auf die Wurzel des autofs Verzeichnises. Was allerdings etwas unerwünscht ist, ist die Tatsache, daß alle Fremdlaufwerke zugleich gemountet werden ohne das es notwendig ist, nur weil eben Nautilus sich hoch arbeitet. Vermute, daß dieser Fehler jedoch lösbar ist, wenn man weiß wo Nautilus dies überwacht oder wie autofs Nautilus mitteilt, daß es gerade den unmount vom aktuellen Laufwerk vornimmt. Denn diese Information muß ausgetauscht werden, sonst würde beim anzeigen nichts passieren und man könnte nicht zusehen, wie sich Nautilus immer einen Ordner weiter nach oben arbeitet. Was das sshfs betrifft, so habe ich mir mal die Mühe gemacht alles mögliche auszutesten. Wegen Cach und all den anderen Funktionen und da ich ein paar Files dabei habe, die ein lock haben, mußte ich das tun, um zu verhindern, daß zwei Personen zugreifen können und sich entweder gegenseitig blockieren oder sie dabei Daten zerstören. Mit sshfs bin ich äußerst zufrieden, weil ich kann mich was das betrifft nicht beschweren. Allerdings muß es im Gesamtsystem irgend wo einen Fehler wegen der Umlaute geben, weil irgend etwas kann damit nicht umgehen, das es zuvor konnte. Denke einfach, daß irgend jemand der das Programmiert hat entweder selbst solche nicht kennt und es nicht bemerkt hat oder, daß man inzwischen Ignorant über diese Fehler hinweg sieht. Allerdings vermute ich eher, daß eben der Programmierer sie selbst nicht nutzt und somit nur den Fehler nicht bemerkt hat. Ähnlich wie der eine C Compiler ein ä,ö,ü,ß als Variablennamen akzeptiert und der andere nicht, obwohl dem ä,ö,ü,ß sonst keine Funktion zugewiesen wird. Es muß also nicht mal am Programm liegen, denn es kann sogar der Compiler einfach anders verarbeiten. Denke in anderen Ländern sind es dann andere Zeichen.
|