Beiträge von Welm

    ... und ALLES draus ist, denkt man sich, das das freigeben sofort möglich ist,...

    Die Daten können auch noch in irgendeinem Puffer liegen und z.B. auf den Abschluss des letzten Schreibvorgangs warten. Aus Sicht des Systems und der Anwenderprogramme kommt es nur darauf an, dass ein lesender Prozess den neuen Inhalt bekommt und nicht, dass der neue Inhalt tatsächlich schon geschrieben wurde -- deshalb ist das Kopieren dann schon "fertig" obwohl noch nicht alles auf dem Stick ist. Das ist eine Optimierung des Arbeitstempos. Deshalb muss man immer abwarten bis das "Auswerfen" oder "sync" beendet ist.

    Warum soll ein externes Programm besser sein als ein Webauftritt der z. B. Sparkasse?

    Also ich benutze beides und man kann die beiden Zugriffsarten beliebig mischen. Das Aufladen von Prepaid-Handys ist z.B. auf der Webseite meiner Bank viel einfacher.

    Das Prüfen der Girokontovorgänge ist dagegen im Hibiscus einfacher.

    Man kann die Vorgänge abhaken solange man sich noch daran erinnern kann oder Belege im Belegeingangskasten liegen (Abhaken und Beleg wegwerfen). Bei seltenen Vorgängen (z.B. Versicherungen, die einmal im Jahr fällig werden) kann man einfach die Beträge und Termine der letzten Jahre mal eben zum Vergleichen nehmen. Privat Versicherte haben viele Überweisungen an Abrechnungsstellen und man sieht den Belegen überhaupt keine Ursache mehr an. Hier kann man automatisch aus dem kryptischen Betreff eine zusätzliche Spalte mit "Dr. Meier" in die Übersicht bekommen ("Kategorien"). Ähnlich ist es, wenn das Restaurant "Andromeda" die Abbuchung als Zahlung an "Drago Museveni" durchführt.

    Info für die, die Hibiscus ausprobieren wollen:


    Die jetzt gesetzlich geforderte Überprüfung der Übereinstimmung von Kontonummer und Name bei Überweisungen etc. führt zu Änderungen im Programm (neuer Dialog z.B. "Die Kontonummer gehört zu Karl Meier. Sie wollten aber an 'Mayer GmbH und Co KG' überweisen. Trotzdem machen?"). Das ist noch nicht eingebaut und soll November/Dezember drin sein. In der Zwischenzeit muss man die Überweisungen also über den Webauftritt der Bank machen.

    Siehe https://www.willuhn.de/wiki/doku.php?id=vop

    Verschiedene User haben ja verschiedene Konfigurationen für den Empfang von Dateien per Bluetooth. Das sendende Gerät gibt aber nur das Empfangsgerät an ohne einen User zu spezifizieren. Wenn auf dem PC nun zwei Leute arbeiten (einer direkt und einer per TigerVNC) wird einfach einer der beiden willkürlich als Empfänger ausgewählt und gefragt, ob er die Datei haben will. Wiederholung des Übertragungsversuchs führt immer wieder auf denselben (falschen) User. Das macht die ganze Übertragungsmöglichkeit unbrauchbar. Gibt es da irgendeine Möglichkeit der Einflussnahme?

    Dann könnte ich wenigstens die gesamte Verzeichnisstruktur systematisch umbenennen und wieder LInux-konform machen.

    Falls es tatsächlich ein so geartetes Problem ist würde Dir das Umbenennen aber nichts nützen. Dann wäre es für den Linux-Rechner richtig kodiert und für den MP3-Player falsch. Dann würde sozusagen der MP3-Player Fragezeichen anzeigen.


    Der Schlüssel zur Lösung ist das Mounten: es muss so gemounted werden, dass beim Lesen und Schreiben immer Dateinamen mit dem "ß" der einen Seite in Dateinamen mit dem "ß" der anderen Seite geändert werden. Das geht irgendwie beim Mounten ... IIRC wird das bei DVDs so gemacht. Wenn Du es also hinbekommst, dass wieder so wie früher gemounted wird, dann verschwindet das Fragezeichenproblem (hoffentlich) gleich mit.

    Hat jemand einen Verdacht, was die Probleme verursachen könnte ?

    Ja. Eine Fehlinterpretation des Charater Encoding. Z.B. macht der eine ISO-LATIN-1 und der andere interpretiert das als UTF-8.


    Bei ISO-LATIN-1 stehen für "äöüß" die Bytes:

    344 366 374 337

    und bei UTF-8 stehen für "äöüß" die Bytes:

    303 244 303 266 303 274 303 237


    Interpretiert man das erste als UTF-8, so sind das zwei Zeichen Unfug und es werden daher zwei Fragezeichen (Im xterm in Weiss auf Schwarz) angezeigt.


    Auch in der umgekehrten Richtung würde Mist passieren, denn die im PC eingetippten UTF-8-Zeichen würden auf dem Player als etwas anderes interpretiert.


    Es gibt beim Mounten Optionen für das Character Encoding. Wenn die passen (oder beim Mounten richtig geraten werden) sollten die Probleme verschwinden. Die hab ich aber nicht mehr parat.

    Das ist schon ganz gut so.


    Wenn man aber auch noch Software außerhalb des Paketsystems installiert, dann sind deren Abhängigkeiten im Paketsystem nicht bekannt und man muss deren Abhängigkeiten selbst im Auge behalten. Das sollte man also möglichst vermeiden, denn man muss es dauerhaft selbst berücksichtigen.

    Hi zusammen,


    beim Übertragen von Fotos vom Android-Handy auf PC per Bluetooth musste ich feststellen, dass GPS-Angaben gelöscht wurden. Ich verstehe, dass z.B. bei Signal allzu persönliche Angaben entfernt werden -- aber beim Kopieren?. Es passiert auch bei der Übertragung aus einer anderen App ("Meine Dateien"). Wenn aber beim Kopieren von Dateien irgendein Bit nicht ankommt, dann ist das m. E. definitiv ein Fehler. Ist die Linuxseite der Übertragung irgendwie an diesem Unfug beteiligt?

    Ich habe meine Dateien und Ordner auf einer eigenen, fest im PC verbauten Festplatte.

    Der Pfad ist /run/media/Frank/Volume

    Dazu habe ich Fragen:
    1. Was ist /run?

    2. Was ist /media? (Ich vermute jetzt mal, alles, was in den PC hardwaremäßig eingebaut wurde, wird hier eingehängt?)

    3. Warum "volume"? Wer hat diesen Namen ausgesucht?

    Das ist sehr ungewöhnlich und wird irgendwann Ärger machen. Die Ordner und Dateien des Users Otto gehören nach /home/otto.


    Wenn Otto nun am Rechner sitzt und eine Speicherkarte, tragbare Festplatte, ... mit dem Namen (Volume Label) "meine_fotos" anstöpselt (mounted), dann taucht dieser Speicher als /run/media/otto/meine_fotos im Dateisystem auf und verschwindet wieder beim Auswerfen des Geräts. "media" ist also ganz im Gegenteil nicht für fest eingebautes gedacht sondern für zeitweilig eingebundene Speichersachen.