Ich versuche, mich an mein neues Pixel 6 zu gewöhnen – das scheint ein etwas steiniger Weg zu sein, da das Teil ein Eigenleben hat, das ich nur schwer vorhersehen kann. Ergo: es macht, was ES will, nicht, was ich will. Das ist ausgesprochen frustrierend… Konkreter Fall: Ich habe einen einfachen Texteditor installiert, um Daten von der Zwischenablage in eine Datei zu schreiben und die über MTP auf das Linux-System zu holen. Problem: die Datei wird unter Files im Pixel 6 angezeigt, das Linux-System bekommt davon aber nichts mit. F5 in Caja ändert daran nichts. Erst wenn ich die USB-Verbindung zum Pixel 6 unterbreche und neu aufbaue, sieht Linux die Datei. Das geht sogar so weit, dass Linux noch nicht einmal Änderungen an der Datei mitbekommt – es greift immer auf die alte Version zurück, die evtl. auf dem Pixel 6 schon gar nicht mehr existiert. Ist das ein Feature, oder ein Bug, oder mache ich irgend was falsch?
Moriz schrieb: > Ist das ein Feature, oder ein Bug, oder mache ich irgend was falsch? Schwer zu sagen: Du schreibst zwar recht viel, aber verpackst recht wenige Infos darin. Insbesondere die, wie das Gerät angebunden wurde, wäre vielleicht nicht ganz unwichtig. Gegebenenfalls würde ich es erstmal via MTP „wie es gedacht ist“, i.e. nicht via irgendwelchem FUSE-Foo als Pseudodateisystem abstrahiert, schauen, ob es grundsätzliche Probleme gibt.
Jack V. schrieb: > wie das Gerät angebunden wurde Über USB – läuft MTP auch noch auf anderen Verbindungen? > Gegebenenfalls würde ich es erstmal via MTP „wie es gedacht ist“, i.e. > nicht via irgendwelchem FUSE-Foo als Pseudodateisystem abstrahiert, > schauen, ob es grundsätzliche Probleme gibt. So tief habe ich da noch nicht hinter die Kulissen gesehen… Wenn ich ein Android-Gerät an den USB anschließe, öffnet sich auf Linux Caja (Mint 21 Mate) und auf dem Smartphone wird abgefragt, ob die Verbindung zugelassen wird. Wenn ja, geht der übliche Zirkus los: Fehlschlag und erneute Abfrage etc. oder Fehlermeldung auf Linux und man kann das Android-Gerät trotzdem öffnen, oder es geht gar nichts und man muss den USB abhängen und einfach nochmal den ganzen Zirkus versuchen. Irgendwann klappt es dann.
:
Bearbeitet durch User
Moriz schrieb: > Wenn ich ein Android-Gerät an den USB anschließe, öffnet sich auf Linux > Caja (Mint 21 Mate) und auf dem Smartphone wird abgefragt, ob die > Verbindung zugelassen wird. Wenn ja, geht der übliche Zirkus los: > Fehlschlag und erneute Abfrage etc. oder Fehlermeldung auf Linux und man > kann das Android-Gerät trotzdem öffnen, oder es geht gar nichts und man > muss den USB abhängen und einfach nochmal den ganzen Zirkus versuchen. > Irgendwann klappt es dann. Seltsam. Wenn ich mein Android-Gerät an USB anschließe, wird auf dem Galaxy Smartphone abgefragt, ob die Verbindung zugelassen wird. Wenn ja, erscheint ein Icon auf dem Debian stable Linux (12) MATE Desktop. Wenn man darauf klickt, öffnet sich Caja und erlaubt vollen Zugriff auf die Daten. Nur mal so als Information das es mit Debian stable durchaus gut funktioniert…
Vergiss einfach MTP. Fuer den Datentransfer vom Wischfon zu einem PC empfiehlt sich der "Total Commander" nebst dem FTP-Client/SMB-Client-Plugin. Aber nicht den aus dem "Blaehstore". Dem fehlen wohl mittlerweile einige wichtige Funktionen... Will Mann nicht auf dem Wischfon "fummeln", bietet X-plore einen integrierten FTP-Server. Den kann Mann dann bequem vom PC aus bewirtschaften. Mancher mag X-plore noch vom Symbianfon kennen. MTP ist eine Seuche wie Bluetoothfileserver, die eine Datei mit der Bemerkung: "Dieser Dateityp wird vom Mobilfon nicht unterstuetzt" ablehnen. Das das $DRECKSDING die evtl. einfach nur "Speichern" sollte, scheint dem Hersteller nicht in den Sinn gekommen zu sein.
Hat schon mal jemand ssh ausprobiert? SimpleSSH bietet neben dem normalen ssh auch scp. Damit kann auch Caja (Linux Mint) umgehen. Blöd ist nur die Sache mit dem Einmal-Passwort bei SimpleSSH. https://www.techrepublic.com/article/how-to-install-an-ssh-server-on-your-android-phone/ 'Nachtrag: SimpleSSH hat nur den kleinen Haken, dass es auf Playstore nicht mehr zu finden ist. Aber es gibt Alternativen.
:
Bearbeitet durch User
Meine Methode ist ein geteiltes und synchronisiertes Verzeichnis auf einem Nextcloud Server. Ich benutze WEBO Cloud. https://webo.cloud/nextcloud/ Das funktioniert für mich prima. Matthias
Irgend welche Clouds kommen für mich nicht in Frage.
Ich habe jetzt einige ssh-Sever aus dem Playstore durchprobiert und nicht einen einzigen zum Laufen bekommen. Es ist immer der selbe Scheiß mit diesem Android-Mist: Beschreibung Fehlanzeige, man ist aufs Rumprobieren angewiesen und das geht eben meistens schief, weil halbwegs vernünftige Fehlermeldungen und Hilfefunktionen ebenso fehlen. Die Entwickler scheinen alle völlig authistisch vor sich hin zu frickeln und zu meinen, alles was sie wüssten, wüsste die ganze Welt… So ein Kindergarten.
Moriz schrieb: > Ich habe jetzt einige ssh-Sever aus dem Playstore durchprobiert und > nicht einen einzigen zum Laufen bekommen. > ... Die drei Hauptfunktionen von Android sind: - Werbung anzeigen - Furzapps ausfuehren - Informationen absaugen Mit jeder neuen Androidversion nimmt die eigentlich einem Linux innewohnende Nuetzlichkeit immer mehr ab. Ernsthafte Entwickler bieten ihre immer noch nuetzlichen Apps mittlerweile selbst an, weil ihre Apps nicht mehr den Bedingungen des Guggelstores entsprechen. Ich habe auf meinem alten(!) Schlaufon mit Android 4, damals dropbear installiert. Der wollte zunaechst auch nicht funktionieren. Das Problem liess sich beheben, wenn man ihn ueber eine Shell uebers Netzwerk startete. Dann erbte er wohl die passenden Rechte auf das Netzwerk und Firewalleintraege um extern erreichbar zu sein. Im Huelfsscript (Auszug): su -c /system/bin/nc -T -l -p23 -e'sh -l' & Das startet man in einem "Terminal". Dann kann man immerhin schon ein passwortloses Telnet auf das Fon machen. nc ist ein mit dem NDK selbst kompiliertes "netcat", und su ein ebenfalls mit dem NDK kompiliertes erweitertes "su". Von einem externen Rechner baut man dann eine Telnetverbindung auf, und kann dort in der Shell schlussendlich den sshd mit sshd starten. Dem sshd habe ich dann noch einen RSA-Key mitgegeben, so dass man nicht mit Fragen nach Passworten belaestigt wird. :) Das netcat sollte man dann wieder beenden. Sonst wird man geh4x0rt... Etwa so: su -c pkill -9 /system/bin/nc Leider wird das auf aktuellen Androidversionen wohl alles nicht mehr funktionieren.
:
Bearbeitet durch User
Moriz schrieb: > Ist das ein Feature, oder ein Bug, oder mache ich irgend was falsch? Und was ist mit neu angelegten Files?
Motopick schrieb: > Die drei Hauptfunktionen von Android sind: > > Werbung anzeigen > Furzapps ausfuehren > Informationen absaugen Das kann man gut in den Griff bekommen, gerade auf den Pixels. https://grapheneos.org/
Moriz schrieb: > So tief habe ich da noch nicht hinter die Kulissen gesehen… Naja … wenn man ’ne Lösung sucht, muss man schon auch danach suchen. Von alleine springt die einen meist nicht an und schreit „Hier bin ich!“. Erste Anlaufstelle wäre für mich das Journal. Dort findet man raus, wie das Pseudodateisystem überhaupt zustande kommt. Dann könnte man z.B. den Automatismus temporär stilllegen, andere Varianten selbst probieren und gucken, ob sich das gewünschte Verhalten erreichen lässt. Logcat auf dem Zielgerät ist auch meist eine Quelle ausgiebiger Informationen, btw.
Moriz schrieb: > Es ist immer der selbe Scheiß mit diesem Android-Mist: Beschreibung > Fehlanzeige, man ist aufs Rumprobieren angewiesen und das geht eben > meistens schief, Du benitzt doch Linux! Dann kennst du das doch!
dass USB manchmal hakelt kenne ich auch. Aber nicht so penetrant. Ein Fundhändy macht das genau wie meins. Steckst das an USB, kommt Bild 01. wischt man das von oben runter kommt das wie in 02. wenn das nicht gleich erkannt wird, diesen kleinen Pfeil nach unten tippen den winkel da neben "Dateiübertragung" dann kommt Bild 03 Da dann auf "weitere USB Optionen" Das führt zu Bild 4 und hier tippst Du z.B. auf "Telefon laden" und dann wieder auf "Dateiübertragung" ...das funzt hier immer.
Das verhalten hab ich mit einem Pixel 2 auch genau so schon gesehen. Das liegt meiner Meinung nach an dem MPT. Selbst Wikipedia schreibt: "Nachteile: - Es ist kein direkter Zugriff auf das Dateisystem möglich ...." Das MPT ist ein emulierter Zugriff aufs Dateisystem. Das bekommt das Telefon anscheinend nicht gescheit emuliert.
Benjamin K. schrieb: > Das MPT ist ein emulierter Zugriff aufs Dateisystem. Das bekommt das > Telefon anscheinend nicht gescheit emuliert. MTP ist in erster Linie ein Protokoll zum Übertragen von Mediendaten, und hat mit Dateisystemen zunächst nichts weiter zu tun. Dass es auf dem Client wie ein Dateisystem erscheint, liegt am FUSE-Pseudodateisystemtreiber des Clients. Dieser muss sich dann aber auch drum kümmern, beim ›ls‹ und bei sonstigen Zugriffen aktuelle Daten anzufordern – es ist ausdrücklich nicht Job des Telefons; das gibt das Protokoll auch gar nicht her. Deswegen meine obenstehenden Vorschläge, das zunächst mal manuell durchzugehen und ggf. einen anderen FUSE-Treiber (jmtpfs, go-mtpfs, …) zu verwenden und zu gucken, ob der’s besser macht. Wenn es um direkten Zugriff auf das Dateisystem des Telefons ginge, würde man sowieso eher über die adb gehen.
:
Bearbeitet durch User
G. K. schrieb: > Und was ist mit neu angelegten Files? Die sieht Caja auch erst, wenn nach dem Anlegen die MTP-Verbindung abgebrochen und neu aufgebaut wurde. Fazit: Caja zeigt nur den Zustand an, der beim Aufbau der MTP-Verbindung herrschte.
Benjamin K. schrieb: > "Nachteile: > - Es ist kein direkter Zugriff auf das Dateisystem möglich > ...." Auf meinem ollen S5 funktioniert die Manipulation des Dateisystems von Linux aus ohne Probleme – wenn denn die Verbindung mal zustande gekommen ist.
Jack V. schrieb: > Wenn es um direkten Zugriff auf das Dateisystem des Telefons ginge, > würde man sowieso eher über die adb gehen. Das S5 kann ich von Caja aus wie ein normales Dateisystem behandeln. Lediglich die Verzeichnisse und Dateien auf dem S5, die per Zugriffsrechten abgeschirmt sind, sind auch für Caja unsichtbar. UND: adb läuft dort nicht. Beim Pixel scheint das doch ziemlich anders zu sein – die verschiedenen Hardware-Hersteller kochen wohl hinter den Kulissen still und leise ihre eigenen Süppchen… Dass auf diese Weise sich das Linux, auf dem Android basiert, auf dem Weg über das ganze GUI-Zeugs zu einem rechten Wackelpudding mutiert, der dann – dank KI – auch noch sein Eigenleben entwickelt, wundert mich so langsam auch nicht mehr. Ich werde jetzt mal noch ftp auf dem Phone probieren – vielleicht habe ich da etwas mehr Glück…
Ich habe gerade vergleichbare/aehnliche Probleme mit einem neuen Tablett mit Android 14 drauf. Ursache ist das Android immer mehr beschneidet auf welche Verzeichnisse ein Programm zugreifen darf. Man kann sich da manchmal mit ein paar Tricks noch drum rummogeln, aber letztlich ist es fuer die eigenen Nerven besser man routet die Kiste und fertig. Vanye
Moriz schrieb: > Das S5 kann ich von Caja aus wie ein normales Dateisystem behandeln. > Lediglich die Verzeichnisse und Dateien auf dem S5, die per > Zugriffsrechten abgeschirmt sind, sind auch für Caja unsichtbar. Wenn dein S5 noch das originale Kitkat draufhaben sollte, wäre das auch einfach erklärt: Unter dem System gab’s noch die Möglichkeit, die Datenpartition wie einen USB-Stick als USB-Massenspeicher einzubinden. Ansonsten: Willst du nun mal endlich gucken, wie das Pseudo-FS des Pixel eingebunden wird, und mal testen, ob es ein grundsätzliches Problem gibt, oder bist du nur zum Lamentieren hier? Im Übrigen würde ich auch mal den Dateimanager als möglichen Fehlerpunkt rausnehmen, und direkt auf der Shell schauen. Wenn der Dateimanager cached oder das Neueinlesen der Daten durch den Dateisystemtreiber nicht triggert, kannst du an den anderen Stellen nämlich auch lange suchen …
:
Bearbeitet durch User
Jack V. schrieb: > Im Übrigen würde ich auch > mal den Dateimanager als möglichen Fehlerpunkt rausnehmen, und direkt > auf der Shell schauen. Wenn der Dateimanager cached oder das Neueinlesen > der Daten durch den Dateisystemtreiber nicht triggert, kannst du an den > anderen Stellen nämlich auch lange suchen … Sorry, ich weiß nicht, wie ich das anstellen soll.
Wenn ich das Pixel 6 an den USB anschließe, erscheinen die folgenden dmesg-Meldungen:
1 | [ 8399.024943] usb 1-12.4: new high-speed USB device number 11 using xhci_hcd |
2 | [ 8399.134456] usb 1-12.4: New USB device found, idVendor=18d1, idProduct=4ee1, bcdDevice= 5.10 |
3 | [ 8399.134468] usb 1-12.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 |
4 | [ 8399.134472] usb 1-12.4: Product: Pixel 6 |
5 | [ 8399.134475] usb 1-12.4: Manufacturer: Google |
6 | [ 8399.134478] usb 1-12.4: SerialNumber: 25 |
7 | [ 8400.847352] usb 1-12.4: USB disconnect, device number 11 |
8 | [ 8401.204863] usb 1-12.4: new high-speed USB device number 12 using xhci_hcd |
9 | [ 8401.317789] usb 1-12.4: New USB device found, idVendor=18d1, idProduct=4ee1, bcdDevice= 5.10 |
10 | [ 8401.317801] usb 1-12.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 |
11 | [ 8401.317806] usb 1-12.4: Product: Pixel 6 |
12 | [ 8401.317810] usb 1-12.4: Manufacturer: Google |
13 | [ 8401.317812] usb 1-12.4: SerialNumber: 25 |
14 | [ 8408.677000] usb 1-12.4: reset high-speed USB device number 12 using xhci_hcd |
15 | [ 8861.638714] usb 1-12.4: USB disconnect, device number 12 |
16 | [ 8866.473039] usb 1-12.4: new high-speed USB device number 13 using xhci_hcd |
17 | [ 8866.574439] usb 1-12.4: New USB device found, idVendor=18d1, idProduct=4eea, bcdDevice= 5.10 |
18 | [ 8866.574456] usb 1-12.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 |
19 | [ 8866.574464] usb 1-12.4: Product: Pixel 6 |
20 | [ 8866.574469] usb 1-12.4: Manufacturer: Google |
21 | [ 8866.574474] usb 1-12.4: SerialNumber: 25 |
Wenn man auf dem Pixel die Datenübertragung per USB frei gibt, hinterlässt das keine Spuren im dmesg. Caja kann auf den P6 Dateien löschen – also sind doch Eingriffe ins Dateisystem per MTP möglich. Lediglich Änderungen, die das P6 gemacht hat, bekommt Caja nicht mit.
:
Bearbeitet durch User
Moriz schrieb: > Wenn ich das Pixel 6 an den USB anschließe, erscheinen die folgenden > dmesg-Meldungen: Im Journal dürften auch die übrigen Sachen stehen. Insbesondere, wer’s wie mountet. Auch die Ausgabe von ›mount‹ mag nähere Informationen preisgeben. Moriz schrieb: > Caja kann auf den P6 Dateien löschen – also sind doch Eingriffe ins > Dateisystem per MTP möglich. Je nach Definition. Dein Dateimanager kann nicht auf das Dateisystem des Telefons zugreifen. Es kann über den Pseudo-Dateisystemtreiber dem MTP-Server auf dem Telefon mitteilen, was es gemacht haben möchte. Das ist ja Teil des Problems hier: Änderungen, die vom Telefon aus gemacht werden, landen direkt im Dateisystem. Dein Dateimanager bekommt das nicht mit, weil er eben nicht auf das Dateisystem des Telefons zugreift, sondern nur eine Nachbildung eines Dateisystems mit den über MTP erhaltenen Daten sieht. Die Zwischenschicht, welche die Nachbildung eines Dateisystems erzeugt, sollte™ beim Aktualisieren der Ansicht im Dateimanager den aktuellen Zustand der Daten vom Telefon anfragen – was hier offensichtlich nicht funktioniert. Tatsächlich würde mich nicht wundern, wenn das auch über andere FS-Treiber nicht gut funktioniert: MTP ist nunmal nicht für sowas gedacht. Nichtsdestotrotz könnte man’s mal durchprobieren.
Ausgabe von mount:
1 | sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) |
2 | proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) |
3 | udev on /dev type devtmpfs (rw,nosuid,relatime,size=16224732k,nr_inodes=4056183,mode=755,inode64) |
4 | devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) |
5 | tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3263144k,mode=755,inode64) |
6 | /dev/mapper/vgmint-root on / type ext4 (rw,relatime,errors=remount-ro) |
7 | securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) |
8 | tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64) |
9 | tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64) |
10 | cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot) |
11 | pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) |
12 | efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime) |
13 | bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) |
14 | systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=28934) |
15 | hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) |
16 | tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime) |
17 | debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) |
18 | mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) |
19 | fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime) |
20 | configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime) |
21 | none on /run/credentials/systemd-sysusers.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700) |
22 | tmpfs on /run/qemu type tmpfs (rw,nosuid,nodev,relatime,mode=755,inode64) |
23 | /dev/sda2 on /boot type ext4 (rw,relatime) |
24 | /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) |
25 | /dev/mapper/luks-2d46dbe3-94c9-4d5f-955f-89bafb3fc00a on /mnt/data type ext4 (rw,relatime) |
26 | /dev/mapper/luks-2d46dbe3-94c9-4d5f-955f-89bafb3fc00a on /home type ext4 (rw,relatime) |
27 | /dev/mapper/luks-2d46dbe3-94c9-4d5f-955f-89bafb3fc00a on /var type ext4 (rw,relatime) |
28 | binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime) |
29 | tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3263140k,nr_inodes=815785,mode=700,uid=1000,gid=1000,inode64) |
30 | gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) |
31 | portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) |
Caja greift über mtp://Google_Pixel_6_25251FDF6005TJ/Interner%20gemeinsamer%20Speicher auf das P6 zu. Jack V. schrieb: > Tatsächlich würde mich nicht wundern, wenn das auch über andere > FS-Treiber nicht gut funktioniert: MTP ist nunmal nicht für sowas > gedacht. Nichtsdestotrotz könnte man’s mal durchprobieren. Was meinst du konkret damit?
:
Bearbeitet durch User
Jack V. schrieb: > Die Zwischenschicht, welche die Nachbildung > eines Dateisystems erzeugt, sollte™ beim Aktualisieren der Ansicht im > Dateimanager den aktuellen Zustand der Daten vom Telefon anfragen – was > hier offensichtlich nicht funktioniert. Das ist dann aber aber das individuelle Problem seines Fílemanagers oder dessen Unterbau/OS-Derivat. Mit einem Nemo Filemanager unter Debian funktioniert das problemlos. Sobald auf dem Smartphone ein File erstellt/gelöscht wird, erscheint/verschwindet es unmittelbar in/aus dem Filetree im Nemo auf PC-Seite. Es gibt aber auch CLI-Tools, bei deren Nutzung das nicht funktioniert. Was auch Nemo nicht anzeigt, ist, wenn ein vorhandenes File, z.B. im Editor, verändert wird. Z.B. wird die neue Größe nicht angezeigt. Lädt man das File dann allerdings physisch in einen Ordner auf dem PC, wird es da in aktueller Form abgelegt. > Tatsächlich würde mich nicht wundern, wenn das auch über andere > FS-Treiber nicht gut funktioniert: MTP ist nunmal nicht für sowas > gedacht. Nichtsdestotrotz könnte man’s mal durchprobieren. Ursprünglich wollte man damit ja platt vorhandene Files von einer Seite auf die andere rüberkopieren.
Michael L. schrieb: > Was auch Nemo nicht anzeigt, ist, wenn ein vorhandenes File, z.B. im > Editor, verändert wird. Z.B. wird die neue Größe nicht angezeigt. Lädt > man das File dann allerdings physisch in einen Ordner auf dem PC, wird > es da in aktueller Form abgelegt. Ich habe nemo installiert, das P6 geöffnet, dort eine Datei mit dem Editor verändert und gespeichert – auch nemo bekommt die Änderung nicht mit, weder die Längenänderung noch den Inhalt.
Moriz schrieb: > Michael L. schrieb: >> Was auch Nemo nicht anzeigt, ist, wenn ein vorhandenes File, z.B. im >> Editor, verändert wird. Z.B. wird die neue Größe nicht angezeigt. Lädt >> man das File dann allerdings physisch in einen Ordner auf dem PC, wird >> es da in aktueller Form abgelegt. > > Ich habe nemo installiert, das P6 geöffnet, dort eine Datei mit dem > Editor verändert und gespeichert – auch nemo bekommt die Änderung nicht > mit, weder die Längenänderung noch den Inhalt. Habe ich doch geschrieben, brauchst Du nicht nochmal zu wiederholen. Wenn Du aber die Datei in einen eigenen Ordner auf Deinem PC abspeicherst, wird dort die aktuelle Datei abgespeichert. Probier's aus. Ich habe nemo installiert, das P6 geöffnet, dort eine Datei mit dem Editor verändert und gespeichert – auch nemo bekommt die Änderung nicht mit, weder die Längenänderung noch den Inhalt. Der von mir beschriebene Unterschied bezieht sich auf folgendes von Dir geschriebenes: Moriz schrieb: > G. K. schrieb: >> Und was ist mit neu angelegten Files? > Die sieht Caja auch erst, wenn nach dem Anlegen die MTP-Verbindung > abgebrochen und neu aufgebaut wurde. > Fazit: Caja zeigt nur den Zustand an, der beim Aufbau der MTP-Verbindung > herrschte. Nemo zeigt neu angelegte Files an bzw. zeigt gelöschte Files bei mir nicht mehr an und zwar unmittelbar ohne Neuaubau der MTP-Verbindung. Also anders als das von Dir beschriebene Verhalten Deines Caja.
:
Bearbeitet durch User
Moriz schrieb: > Caja greift über > mtp://Google_Pixel_6_25251FDF6005TJ/Interner%20gemeinsamer%20Speicher > auf das P6 zu. Dann macht’s das selbst, bzw. über gvfsd – da hab ich wenig Ahnung von. Ich würde weiterhin schauen, das mal manuell durchzugehen, und auch mal selbst zu mounten, etwa via go-mtpfs oder jmtpfs, und zu gucken, ob die Sachen dann beim ›ls‹ die Daten neu holen. Moriz schrieb: > Jack V. schrieb: >> Tatsächlich würde mich nicht wundern, wenn das auch über andere >> FS-Treiber nicht gut funktioniert: MTP ist nunmal nicht für sowas >> gedacht. Nichtsdestotrotz könnte man’s mal durchprobieren. > > Was meinst du konkret damit? Wie oben geschrieben: MTP ist nicht für diese Art der Nutzung entworfen worden, also ein Dateisystem abzubilden, bei dem wahlfrei und dynamisch auf die Dateien zugegriffen wird. Es ist dafür gedacht gewesen, das Gerät anzuschließen, statische Mediendateien auf das Gerät zu schubsen oder von dort zu holen, und das Gerät wieder abzustöpseln. Dass Leute angefangen haben, es als Pseudodateisystem zu missbrauchen, war wohl der Tatsache geschuldet, dass USB-Massenspeicher nach Kitkat oder so rausgeflogen ist, und man’s eben nicht mehr direkt mounten konnte.
Ich habe jetzt primitive ftpd von f-driod mit Filezilla ausprobiert. Das funktioniert, wenn man dem ftpd volles Zugriffsrecht auf alle Dateien gibt. sftp funktioniert auch – das scheint eine weniger holprige Lösung zu sein, als mt MTP. Die Quellen sind auf https://github.com/wolpi/prim-ftpd zu finden, sogar mit etwas Beschreibung! Nachtrag: Mit Caja (und nemo) kann man den Server unter Netzwerkverbindungen finden, nachdem man einmal die ftp-Adresse mit Usernamen und Port eingegeben hat. (Nach der Eingabe wird ein leere Verzeichnis namens storage angezeigt – da gehts nicht weiter.) Abfragen, ob Zugriff auf dem Phone gewährt werden sollen, gibt es nicht. Public Key Authentifizierung kann ftpd auch – muss ich noch ausprobieren.
:
Bearbeitet durch User
Jack V. schrieb: > Je nach Definition. Dein Dateimanager kann nicht auf das Dateisystem > des Telefons zugreifen. Es kann über den Pseudo-Dateisystemtreiber dem > MTP-Server auf dem Telefon mitteilen, was es gemacht haben möchte. Jetzt bin ich mal extrem gespannt welche Unterschiede du zwischen einem Pseudo-Dateisystemtreiber und Dateisystemtreiber definierst.
G. K. schrieb: > Jetzt bin ich mal extrem gespannt welche Unterschiede du zwischen einem > Pseudo-Dateisystemtreiber und Dateisystemtreiber definierst. In meinem Sprachgebrauch: Ein Pseudodateisystemtreiber bildet Daten, die nichts mit einem Dateisystem zu tun haben, in einem Pseudodateisystem ab. Beispiel: MTP via go-mtpfs Ein Dateisystemtreiber dient hingegen dazu, auf ein tatsächlich existierendes Dateisystem zuzugreifen. Beispiel: NTFS via ntfs-3g
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.