Wie kann ich konkrete Textstellen aus einer Datei (in diesem Fall Dateinamen) mit der Kommandozeile anzeigen bzw. herausschreiben?

[pit234a]

Allerdings würde ich hier prinzpiell das Backup hinterfragen da es nunmal maximal schlecht gemacht ist und hoffentlich auch niemand sowas verwendet, es sei denn er denkt sich Bespiele für rsync -u aus

ok. Alle meine Strategien hängen halt nun seit Jahren an rsync und das hat so auch immer gut funktioniert und zwar ganz genau in dem von dir beschriebenen Sinn. Ich möchte ja gar nicht, dass ich mir von einem anderen Rechner plötzlich ältere Dateien in mein Backup-Ziel verpflanze.

Allerdings spüre ich auch schon geraume Zeit Bedarf für eine Änderung, denn mit rsync muss ich doch immer noch meinen Kopf ziemlich klar halten und besonders bei den automatischen Backups in der Nacht kann es auch vorkommen, dass ich bewährte Dateien im Ziel überschreibe, die ich vielleicht noch in der Bearbeitung hatte und gar nicht gerne verlieren wollte. Ein wenig helfen ja snapshots dabei.

Wir dürfen da natürlich diesen Thread nicht kapern und werden ja OT. Aber vielleicht ist es erlaubt, nur mal einige Stichworte zu modernen Backup-Konzepten mit FreeBSD einzuwerfen, die ich mir dann mal googeln kann, um was zu lernen.
zfs send habe ich indessen schon probiert und wurde damit nicht glücklich.

 

[medV2]

Ein Backup bedeutet für mich: Ich habe den Quellordner 1:1 auf dem Ziel. Ohne Ausnahme. Was du beschreibst - dass du Datein irgendwie bearbeitest und die dann von einem Backup überschrieben werden, lässt erahnen das du eventuell sowas wie ein Synchronisationstool für gewisse Ordner suchst? Da wäre dann z.b. syncthing eine Lösung. Oder gar ein Versionierungstool wie git.

Ich persönlich mache die erste Stufe meiner Backups privat auch mit rsync - spricht ja auch absolut nichts dagegen und ist universell wärend z.b. zfs send weder bei meinem Linux Notebook noch meinem GamingPC mit Windows funktioniert. Nach einen rsync folgt immer ein snapshot. Jeder Backupclient (also Notebook, RPIs, Desktop, ...) ist dabei ein eigenes Dataset. Denke das fehlt bei dir gerade, sehe ich aber als wichitg an - um eben von dir beschriebenes Verhalten auszuschließen.

Als zweite Stufe kommt zpaq zum Einsatz, die Archive werden dann verschlüsselt in der Cloud gespeichert.

Beruflich kommt bei uns in der Firma Bacula zum Einsatz, aber ich denke für den Heimgebraucht ist das ein absoluter Overkill.
Borgbackup verwende ich auch manchmal für kleineres - das könnte schon eher was für dich sein, ist aber auch komplexer als rsync.

 

[cabriofahrer]

Ich wollte mich für alle Beiträge hier bedanken und kurz auf einiges eingehen.

Falls der Dateitransfer via MTP erfolgt ist, können auch die vermeintlich erfolgreich kopierten Dateien defekt sein. MTP ist leider ein miserables Protokoll mit noch schlechteren Implementierungen.

Im Zweifelsfalle ist adb das bessere Tool für den Transfer.

Der Dateitransfer ist sicherlich via MTP erfolgt, auch wenn das im Android Menü nicht explizit so genannt wird. Denn die andere angebotene Option ist "PTP". Von daher ist dieser Verweis sehr interessant und wird sehr wahrscheinlich auch die Ursache für die nicht kopierten Dateien sein.

alle meine Kabel sind ja auch Ladekabel

Könnte dies auch ein Grund sein für eine nicht optimale Verbindung?
Ich hatte rsync nie vorher verwendet, deswegen hier besonderen Dank für die Anregung und weiteren Ausführungen zum Thema. Ich denke, die Flag "-auv" wäre hier im Fall das Richtige gewesen, wenn es denn funktioniert hätte.
Das Mobiltelefon gehört nicht mir, aus dem Grund werde ich jetzt nicht ein fsck machen und nach dem hier Gesagtem scheint doch alles auf die Unzulänglichkeiten von MTP hinzudeuten. Dazu weitere Anhaltspunkte:
Zweck der ganzen Aktion war letztendlich sowieso, den Speicher des Telefons massiv zu leeren. Beim Ausführen von rm *.* im Verzeichnis, in dem die Bilder enthalten waren, hängte sich das Terminal auf, bzw. der Prompt wurde nicht mehr freigegeben.
Beim erneuten Herstellen der Kabelverbindung war das Verzeichnis aber dann doch leer.
Danke auch für den Hinweis mit adb. Hat aber nichts mehr genützt, da das Verzeichnis wie gesagt doch schon leer war. Hier ist aber auch folgendes passiert: Beim Ausführen von adb kill-server wurde der Prompt im Terminal wieder nicht freigegeben. Deutet also doch alles auf eine langsame und schlechte Verbindung hin. Laut usbconfig ist die Verbindung aber "schnell" (480 Mbps):

# usbconfig
ugen7.1: <Intel EHCI root HUB> at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen4.1: <Intel UHCI root HUB> at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen5.1: <Intel UHCI root HUB> at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen3.1: <Intel EHCI root HUB> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen6.1: <Intel UHCI root HUB> at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen1.1: <Intel UHCI root HUB> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen0.1: <Intel UHCI root HUB> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen2.1: <Intel UHCI root HUB> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen7.2: <PixArt Imaging Inc. USB2.0Camera> at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
ugen6.2: <hp photosmart 7600 series> at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (2mA)
ugen1.2: <RAPTOR-GAMING RAPTOR-GAMING LM1> at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
ugen2.2: <SEM USB Keyboard> at usbus2, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (98mA)
ugen7.3: <Android Android> at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

Das Modell ist ein "Redmi 4A" mit einer 7.1.2 Android Version.
Noch zu adb allgemein: Sicherlich eine tolle Sache, allerdings muss man da vorher die "Developer Otpions" aktivieren und dann USB zulassen. Zum Tipp die Karte zu entfernen und direkt an den PC zu stöpseln: Habe ich auch schon gemacht, setzt aber voraus, dass es eine zweite "externe" Karte ist, und nicht die interne. Und trotzdem muss man bei einer zusätzlichen Karte auch vorher das Telefon ausschalten und das Gehäuse öffnen. Also eigentlich keine Option...

 

[pit234a]

Und trotzdem muss man bei einer zusätzlichen Karte auch vorher das Telefon ausschalten und das Gehäuse öffnen. Also eigentlich keine Option...

vielleicht bei der Anschaffung gleich auf so etwas achten.

Ich selbst besitze gar kein Mobil-Telefon, aber die letzten Geräte, die mir mein Arbeitgeber überlassen hatte, konnten alle im Betrieb einfach die zusätzliche(n) (micro)-SD-Karten entnehmen lassen.
Ob es damit zusammenhängt, dass womöglich die benutzten Android-Versionen neuere sind, die das Entnehmen und Wiedereinlegen der Karte im Betrieb besser verdauen, weiß ich nicht und kann auch gar nicht die Version bei mir auslesen. Als ich vor Jahren aber mal für einen Bekannten mit einer Android-VM für die x86 Plattform spielte, meine ich, dass damals bereits hierfür eine Version 8.6 oder sogar 9.1 benutzt worden war. Wie gesagt: vor Jahren schon größer, als das nun bei dir der Fall ist.

Ich meine mich auch zu erinnern, dass es damals eine Art Kompatibilitätsliste gab, welches Android mit welchem MPT gepaart was für Funktionen ermöglichte. Die wurden im Laufe der Zeit ja auch weiter entwickelt und ich könnte mir vorstellen, dass eine recht alte Android-Version vielleicht eben noch nicht alles kann, was moderne Versionen heute machen und dass womöglich sogar Probleme zwischen weit entfernten SW-Versionen bestehen könnten.

Außerdem funktionierte es bei mir stets sehr viel besser, wenn ich Geräte über USB3 angeschlossen hatte. Trotzdem bleibt das unzuverlässig. Vermutlich auch, weil das Handy einfach nicht für so etwas gemacht ist. Es erkennt hauptsächlich USB als Strom-Quelle. Datenübertragung will es doch lieber über Wlan oder Bluetooth abwickeln. Wenn es dann in seinen "Suspend-Modus" geht, nimmt es womöglich die Datenübertragung einfach weg.
Außerdem sehe ich bei dsbmc ein solches Verhalten: erst wird das Gerät erkannt und angezeigt. Will es dann per Klick eingebunden werden, kommt zunächst eine Bestätigungsaufforderung am Gerät selbst und nach Aktivieren wird dann von dsbmc wieder das gleiche Gerät angezeigt und kann nun eingebunden werden. Dieser Vorgang ist ein wenig zeitkritisch und als ich vor dsbmc die Geräte manuell eingebunden hatte, fehlte hier womöglich ein wenig von dem, was @marcel in dsbmc eingebaut hat. Obwohl ich den Eindruck hatte, dass es tatsächlich einfacher und unproblematischer mit dsbmc funktionierte, gab es doch immer wieder Pannen, vor allen Dingen, bei länger stehenden Verbindungen. Also nicht, wenn mehrere Daten am Stück übertragen werden, sondern nach einigen Minuten Stillstand mal wieder auf das Gerät zugegriffen werden soll.

Nebenbei: Android Geräte funktionierten da bei mir noch besser, als IOS Geräte.
Wenn ich keine extra SD-Karte im Gerät hatte, habe ich mir in einem Fall einen Adapter gekauft, über den ich dann eine Karte extern anschließen und innerhalb des Gerätes die Dateien zunächst auf diese Kopieren und dann am PC auslesen konnte. Das war aufwändiger, aber tatsächlich mit weniger Ärger verbunden, als die häufigen Abbrüche bei direkten Kontakt zum Gerät.

 

[Andy_m4]

Die besten/unkompliziertesten Erfahrungen bezüglich PC <-> Android via MTP habe ich mit dem Programm
android-file-transfer (https://github.com/whoozle/android-file-transfer-linux)
gemacht.

 

[medV2]

Ich spreche jetzt nur für Android:

MTP ist eigentlich kein Problem mehr. Der Standard ist mit den Smartphones gewachsen und die letzten 5 Jahre oder so klappt das auch alles recht zuverlässig.

OP hat jetzt ein Android was 8 Jahre alt ist, kA wie es damals war, aber ich schätze das war die Zeit wo es gerade im Wandel war. Genug Alternativen zu MPT wurden ja genannt.

 

[cabriofahrer]

MTP ist eigentlich kein Problem mehr. Der Standard ist mit den Smartphones gewachsen und die letzten 5 Jahre oder so klappt das auch alles recht zuverlässig.

Nun, es handelte sich wie gesagt nicht um mein Gerät. Heute habe ich von meinem eigenen Gerät mit Android 11 Go eine Verbindung hergestellt und problemlos einige Video- und Bilddateien übertragen.

 

[double-p]

Danke fuer den Hinweis mit adb; ich habe jetzt USB-debug an (Developer Mode war schon fuer NoSensors am Start) und habe neben dem adb SDK noch adbsync ( https://github.com/jb2170/better-adb-sync ) installiert.

Das ergibt ein rsync-aehnliches Verhalten mit ziemlich wenig Aufwand (kein rooten, kein rsync compile, ...einfach via USB, kein extra WiFi setup) - und es ist schon gefuehlt viel schneller als all die mtp/ptp basierten transfers wie zB das unsaegliche android-file-transfer.