Aus den Angeln hebender Reinfall bei Backup ins Internet

Wenn das im Default bei Installation des "normalen" rsync-Pakets passiert, ist das Paket kaputt. rsyncd ist eine NIschenlösung für eine sehr seltene Anwendung; ich gehe davon aus dass weit über 90% der rsync-Installationen keinen lokalen DAaemon brauchen.

Das ist eine Binse. Du bräuchtest aber keinen rsync-Daemon.

Schalt ihn halt aus. Du brauchst ihn nicht.

Du solltest Kryptografie wirklich den Spezialisten überlassen.

Grüße Marc

und dabei natürlich deutlich schlechter bist als das was die Experten gebaut haben.

und dabei Probleme mit dem Dateitransfer hast und Dich standhaft weigerst, diese Problem zu debuggen und stattdessen krude Splitmechanismen implementierst anstell einfach die Standardlösung zu nehmen, die mit diesen Problemen selbst im ungedebuggten Zustand deutlich souveränder umgeht

und wieder nix gelernt.

Grüße Marc

Weil Du rsync nicht kennst, das Deinen großen Upload beim näcshten Aufruf einfach an der Stelle fortsetzt wo er abgebrochen wurde.

So macht das die Welt und die Lösung ist gut.

Aber warum?

Da geht es um einen ziemlich quantitativen Vergleich des mit unterschiedlichen Antriebsprofilen von Schraubenköpfen maximal erreichbaren Drehmoments und deren Cam-Out-Tendenz.

Sag. Bei welchen relevanten Schrauben und Schraubverbindungen wäre denn kein Drehmoment "vorgeschrieben", d. h. angegeben? Und wie manifestiert sich das in der Praxis? Sieht man doch jeden Tag, dass Handwerkern und Mechanikern der Drehmomentschlüssel oder -schrauber buchstäblich in die Hand wächst. Auch bei Getränkeflaschen, usw. ist extremste Vorsicht geboten. Was da alles passieren kann!

Oh die Eitelkeit. Das o. g. Video ist im Vergleich geradezu wissenschaftlich aufgemacht (Torque Test Channel never disappoints!) und davon ab werfe den ersten Stein, wer noch nie eine Schraube überdreht, ein Gewinde ausgerissen oder einen Schraubenkopf vergnaddelt hat.

Mit meinem Bosch GSR 12V-35 FC und dessen brachialem, elekektronisch kommutierten Motor passiert mir das sogar regelmäßig, wenn ich mal wieder zu faul bin "wegen der einen Schraube" den Drehmomentbegrenzer zu nutzen.

Volker

Sowas aber auch.

/ralph

Nur der Vollständigkeit halber: Wenn das Teil 7/24 Online ist, würde ich nicht unbedingt von einer "Sicherung" sprechen. Ein kleines Überspannungsereignis und der Rechner mit der ersten Ausfertigung des Datenstands ist genauso im Eimer wie das an derselben Steckerleiste, Router, DSL-Modem, usw. hängende NAS.

Was sind denn die "wichtigsten Backups"? Ist das nur eine Unermenge des Datenbestands oder ein bestimmter Zeitpunkt der Rotation?

Gib die Hoffnung mal schleunigst auf. Haben ist besser als brauchen. So ein NAS hat noch viele andere Vorteile, nicht nur Datensouveränität. _Parallel_ den Hoster zu nutzen, ist gar keine schlechte Idee. Wäre bei mir aber schwierig, nicht nur wegen der Bandbreite, sondern auch, weil ~8TB extern gar nicht mehr so günstig sind und das vollmundig versprochene GBit-Internet mit FFTH auf sich warten lässt.

Da ist mir das Netgear RN214 mit Link-Aggregation deutlich lieber, muss aber zähneknirschend immer mal wieder eine externe Festplatte im USB3-Gehäuse anhängen. Die sind zwar auch nicht billig, aber im Vergleich zu irgendwelchen LTO-9-Systemen

Volker

Die Schrauben in diesem "Test" haben wohl keine Festigkeitsklasse. Und die dann auch noch in Aluminium einzudrehen ...

Dass bei diesem Walzblei der Kopf abreißt oder der Ansatz vermurkst, ist nicht wirklich überraschend.

In des tumben Toren Hand ...

Danke für die Bestätigung, dass Du weder gelesen hast, was ich schrieb, noch verstanden, worum es im Test (gerne auch ohne Anführungszeichen) ging.

Auch bei 12.9 kann ich den Kopf abreißen, muss es nur schlau genug anstellen. Wenn es im Test um das mit Schraubverbindungen maximal erreichbare Spannmoment gegangen wäre (falls man sich für diesen in der Praxis außerhalb von Herstellungsprzessen weitestgehend irrelevanten Wert überhaupt interessieren sollte), hätte der Aufbau natürlich anders ausgesehen.

Ich war jedenfalls dankbar für den Überblick, wie sich der bei Holz- bzw. Blechschrauben immer extrem gehypte Torx-Plus-Antrieb gegenüber dem herkömmlichen Torx schlägt und wie im Vergleich Kreuzschlitz (PH oder PZ) dasteht. Innensechskant und Triwing sind sowieso Exoten, die niemand verwenden würde, der noch alle Tassen im Schrank hat. Und wer auf Schlitzschraubenniveau sinkt, muss ein Masochist sein. Das mag für die Renovierung dekorativer Schrauben an Antiquitäten noch angehen, aber sonst halte ich davon nur Eines: Großen Abstand.

Joah. Verbindlichsten Dank. Wann hattest Du denn das letze Mal einen Schraubendreher in der Hand? Also nicht zur Maniküre. Maschinenbau, Kraftfahrzeuge, Blech, Holz (idealerweise was mit mehr "Charakter", d. h. Buche oder Eiche)?

Volker

Allerdings. Gerade mal getested auf FreeBSD 15.1-RELEASE: "pkg add rsync" installiert das rsync-Paket, jedoch läuft der Daemon nicht automatisch - dies entspricht der Erwartungshaltung. Es wird ein Startskript für den Daemon als "/usr/local/etc/rc.d/rsync" installiert, dieses erfordert für den normalen Start (entweder automatisch beim Booten oder manuell via "/usr/local/etc/rc.d/rsync start" den entsprechenden /etc/rc.conf Eintrag: "rsyncd_enable=YES" welcher selbstverständlich nicht bei Installation automatisch gesetzt ist und manuell eingetragen werden muss.

Das Paket (oder der Port, um FreeBSD Sprachgebrauch zu verwenden) rsync verhält sich also - wie erwartet - vernünftig.

Als entweder hat der Herr Schellong da einen selbst verbastelten Fork des Ports am Laufen oder erzählt Unfug ...

Tja.

Man liest sich, Alex.

Seltsame Ideen und stolz darauf?

SCNR, Alex.

Manchmal ist es nicht NIHS, sondern weil verfügbares Zeugs aus irgendeinem Grund das konkrete Problem nicht löst. Dann wird man aber möglicherweise auf verfügbarem Zeug aufsetzen, vielleicht einen PR auf GIT einreichen und die Community an der Verbesserung teilhaben lassen, anstatt im stillen Kämmerchen irgendwas Halbgares zusammenstricken.

Ich hatte neulich ein Problem mit dem Relink/Repair-Feature von Lightworks

Also schrieb ich mir selber eine schlauere Alternative in C++17:

Und, ja, ich bekenne mich hier ebenfalls des NIHS schuldig, d. h. den FNV-1a 64- bit Hashalgorithmus reimplementiert zu haben. Weil ich mir wegen 100 Zeilen Code keine Abhängigkeit zu Crypto++ ans Bein binde.

In der Grabbelkiste liegt auch noch WinLayout.exe, weil es mich irgendwann final ankekste, wenn ich mich @home per Remote Desktop mit dem Win11-Rechner @work verbinde und dann am nächsten Tag vor Ort Windows die ganzen Fenster durcheinandergewurschtelt hat, weil das Monitorlayout daheim und vor Ort unterschiedlich war.

Dafür gibts verblüffenderweise kein leichtgewichtiges CLI-Tool, weswegen ich mir mit C++ einen robusten Matching-Algorithmus anhand von vorher abgespeicherten Parametern wie zum Fenster gehöriges EXE, Fenstertitel, Klasse, Position und Größe, einem unscharfen Titelvergleich (Longest Common Substring) aus der Nase gezogen habe und die Kandidaten per Hungarian-Algorithmus optimal 1:1 zuordne.

Das klappt (u. A. bei maximiertem MS VS Code) nicht immer 100%ig, aber 17 von 18 Fenster wieder an der richtigen Stelle spart trotzdem Nerven.

Würde ich rsync imitieren? Oder split reimplementieren? Nie im Leben. Irgendwelche selbst hergestellten Dateifragmente im Internet ohne Prüfsumme hin- und herzuschicken, weil irgendein Provider längere Uploads abwürgt, ist doch sowieso ein Selbstmordkommando. Was gibts an:

ssh-keygen -t ed25519 ssh-copy-id snipped-for-privacy@webspace.example.com rsync -avh --progress --partial --append-verify \ ~/temp/archive.tar.gz \ snipped-for-privacy@webspace.example.com:/path/to/webspace/

auszusetzen?

Volker

FreeBSD ist durchaus eigen und selbstbewußt. Sie haben schon manches dauerhaft aus dem System entfernt. rsync gehört z.B. nicht zum System, weil diese Exe /usr/local/bin/rsync lautet.

Das überrascht mich nicht, ungefähr so dachte ich mir das.

Wirklich gängig waren damals sh, csh, ksh, awk. zsh bekannt, aber nicht gängig.

Bis vor kurzem war csh die Login-Shell unter FreeBSD. Unter FreeBSD Rel.15.1 sah ich erstmals /bin/sh als solche. Hab ich geändert.

Ein Kenner wird wissen, daß der Inhalt nicht durch übliche Verknüpfung per XOR entstanden ist. Ich sprach ja selbst von eingeschränkter Wertmenge. Allerdings die Anzahl von Verschlüsselungsvorgängen ist unbekannt.

Eine Entschlüsselung ist nur durch den einen genau passenden Schlüssel möglich. Wird ein unpassender benutzt, bricht das Kommando hochwahrscheinlich per Exit ab.

Früher sah ich oft so etwas wie Cygwin...

Ich sah unter Windows, daß MS-VC v22 installiert sei. Ich muß da mal weiter untersuchen, weil ich nicht an ein klassisches Installiertsein glaube.

Aber bei Gnu werde ich mal nach einer Exe-64 für Windows schauen. Eine Quelle für Kompilierung unter _Windows_ habe ich noch nie gesehen.

Generell kompiliere (clang) und nutze ich bish unter FreeBSD.

SYNOPSIS . Local: rsync [OPTION...] SRC... [DEST] . . Access via remote shell: . Pull: rsync [OPTION...] [USER@]HOST:SRC... [DEST] . Push: rsync [OPTION...] SRC... [USER@]HOST:DEST . . Access via rsync daemon: . Pull: rsync [OPTION...] [USER@]HOST::SRC... [DEST] . rsync [OPTION...] rsync://[USER@]HOST[:PORT]/SRC... [DEST] . Push: rsync [OPTION...] SRC... [USER@]HOST::DEST . rsync [OPTION...] SRC... rsync://[USER@]HOST[:PORT]/DEST

Warum? Und inwiefern?

Meine vielen Implementationen davon sind alle erfolgreich.

Du spinnst. Ich verwende _mehrere_ Verschlüsselungs-Algorithmen, nur einen entwickelte ich selbst. Und diesen einen habe ich so aus Spielerei entwickelt.

Ich habe _viele_ kryptographische Algorithmen implementiert. Mittels rfc-Texten, NIST-Texten und anderen Dokumentationen. Alles gelungene Implementationen.

Diese behauptete Standard-Lösung erfüllt überhaupt nicht meine Anforderungen.

Hirnloser, behauptender Spruch.

Am 11.09.26 um 20:44 schrieb Helmut Schellong:

stat und lseek sind keine Windows-Funktionen. Linux konnte Large Files mit 32 Bit noch nie wirklich.

Win32 SetFilePointer konnte AFAIK schon immer 64 Bit.

Für Borland C Compiler braucht man aber auch eine gewisse masochistische Ader. Die IDEs waren nett, aber die haben oftmals ein anderes Programm compiliert, als man geschrieben hat, vor allem wenn die Optimierungen an sind.

Nimm Cygwin64.

Ja, entweder direkt Windows-API oder halt 64 Bit.

Dann nimm gcc. Cygwin64 ist nichts anderes als der Windows-Port von dem ganzen Geraffel. Damit funktionieren selbst Shell-Skripte unter Windows

- wenn man sich das geben will.

Marcel

Ich kenne reget-Mechanismen und verwandte. Jedoch die Lösung mit rsync erfüllt überhaupt nicht meine Anforderungen.

Jedoch die Lösung mit rsync erfüllt überhaupt nicht meine Anforderungen. Ich berichtete.

Um Dateien automatisch splitten und wieder zusammenbauen zu können. Allein im Zusammenhang mit FAT-Systemen ist/war das hin und wieder notwendig.

Heute. T6, um das Gehäuse eines Garmin-Navis zu eröffnen.