Beiträge von KB19

    Wollt ihr etwas lustiges hören? :S

    PHP-Projekt (CLI), der letzte Commit vor ca. einem Jahr. Vorhin wollte ich ein neues Feature dafür programmieren, klappte einwandfrei. Nach ersten echten Konfigurationsänderungen die Ernüchterung: Da funktioniert überhaupt nichts mehr, sobald ich die neuen INI-Direktiven verwende…

    Ursache: Ich habe nicht bedacht, dass kleingeschriebene Konfigurationsvariablen einen speziellen Zweck erfüllen. Ich hätte es somit in Großbuchstaben einprogrammieren müssen. Der Hammer daran ist nur, dass diese Tatsache riesengroß in der Beispielkonfigurationsdatei dokumentiert ist, die ich wenige Minuten zuvor ergänzt habe! Insofern trifft RTFM sogar bei eigenem Code zu, wenn man diesen nach längerer Pause wieder anrührt. :D

    (Und wieder eine halbe Stunde mit unnötigem Debuggen vergeudet.)

    Wo widerspricht das jetzt meiner Aussage?

    Du hast ursprünglich geschrieben:

    RSync benutzt den Checksummenvergleich nur, falls sich Größe oder Mtime der Datei geändert haben. Oder falls man `-c` angegeben hat.

    Und der erste Satz stimmt eben nicht.

    rsync überprüft die Prüfsumme nur, wenn man --checksum angegeben hat. Und dann eigentlich nahezu immer, außer die Dateigröße hat sich geändert.

    Soll heißen: rsync --checksum überprüft die Prüfsumme auch, wenn size/mtime identisch sind. Hingegen rsync [--no-checksum] vergleicht die Prüfsummen nie, auch nicht, wenn sich size/mtime geändert hat. Ohne --checksum kommt es somit immer zu einer Übertragung, sobald size/mtime anders sind – auch bei identischem Inhalt!

    Das Problem kenne ich nur zu gut. Ich hatte hier mal jahrelang diverse Netzwerk und USB-Kabel als Leichen hinter Kästen rumliegen. Die waren gar nicht mehr in Verwendung, konnten aber erst Jahre später entfernt werden, weil man sie nicht sauber heraus ziehen konnte…

    RSync benutzt den Checksummenvergleich nur, falls sich Größe oder Mtime der Datei geändert haben. Oder falls man `-c` angegeben hat.

    Nicht ganz richtig: Wenn sich die Größe geändert hat, wurde die Datei offensichtlich verändert. Dann erfolgt immer eine Übertragung. Ob die ganze Datei neu übertragen wird, hängt davon ab, ob der Delta-Algorithmus aktiv ist.

    Ohne --checksum findet niemals ein Prüfsummenvergleich statt! In diesem Fall wird standardmäßig nur die Dateigröße und Modification-Time vergleichen. Es könnte somit jemand den Inhalt der Datei verändern, ohne dass es rsync bemerkt:

    Die Dateien haben nun einen unterschiedlichen MD5-Hash, trotzdem findet ohne --checksum keine Übertragung statt.

    […] Checksummen basierte Prüfung […]

    Wenn man dieses Feature verwendet, ist eine hohe Auslastung nicht verwunderlich. rsync muss dann alle (!) Dateien mindestens einmal vollständig von der HDD lesen.

    Wenn man sich hingegen nur auf Dateigröße und Modification-Time verlässt, geht der Abgleich wesentlich schneller und braucht kaum Ressourcen. Außer bei Beibehaltung der Hardlinks und vielen Dateien, das kostet natürlich massiv RAM. Ob man einen Prüfsummenabgleich wirklich braucht, hängt vom zu synchronisierenden Inhalt ab, und wer darauf Zugriff hat.

    Ein zusätzliches (POST) Formular hat halt wieder den Nachteil, dass eventuell einige Nutzer abspringen oder die Bedienung nicht verstehen.

    Eine alternative oder zusätzliche Lösung wäre meiner Meinung nach, dass die Bestätigungsseite die Aktion über JavaScript auslöst. Bei Bots passiert somit hoffentlich nichts, bei aktiviertem JS wird ein Ajax-Request ausgelöst und ohne JS bietet man als Fallback einen Submit-Button mit POST-Formular an.

    Wenn man sich wundert, warum die neue Backup-HDD zu Hause nur so schleppend voll wird, obwohl der rsync-Task mit Millionen kleiner Dateien seit Tagen läuft, hat man eventuell einen Bug in die Bereinigungsfunktion einprogrammiert, der die soeben abgeschlossenen Tasks gleich danach wieder löscht.

    Fazit: Ich habe den Symlink zum neuesten Backupordner falsch behandelt! Dieser wurde fälschlicherweise wie ein altes Backup angesehen, aufgelöst und gelöscht… <X

    Gerade wer so einen Mail-Setup fährt, der hat etwas mehr Ahnung, dessen Server wird besser abgesichert sein und der klickt auch nicht blind auf jeden Link drauf.

    Dieses Feature wird afaik sogar von Gmail angeboten und beworben. Ich kenne da einige Nutzer, die eher zur DAU-Kategorie gehören und trotzdem so etwas nutzen.

    Alleine von der Verbreitung her, würde ich schon sagen, dass sich das für Spammer lohnt. Jetzt könnte man natürlich darüber streiten, ob Script Kiddies das umsetzen können… ^^

    Durch das Trennzeichen „+“ kann man individuelle Kennungen als Absenderadresse verwenden, ohne sie vorher anlegen zu müssen.

    Birgt halt leider die Gefahr, dass ein böses Script das erkennt und Dich gleich auf der Hauptadresse zuspammt. Damit ist der Nutzen gleich Null.

    Genauso halte ich wenig von erratbaren Aliasen: Wenn jemand ebay@ verwendet, hat er wahrscheinlich auch amazon@ oder paypal@ - deshalb lieber gleich Zufalls(hex)strings als Alias und diese intern notieren, wo sie dazugehören.

    Was die ursprüngliche Frage betrifft: Ja, ich nutze für diesen Zweck eine eigene Maildomain.

    Meine allererste 6 TB Festplatte begrüßt mich beim SMART-Test so:

    Testing has begun. Please wait 694 minutes for test to complete. Test will complete after Thu May 23 07:37:45 2019

    Ok… :sleeping:

    Wenn man die Todesstatistik senken wollte, so müsste man schon auf 80 km/h begrenzen, denn bereits ab 80 steigt die Wahrscheinlichkeit eines tödlichen Ausgangs bei einem Unfall sprunghaft an.

    Hey, warum nicht? Wäre ich sofort dabei bei diesem Vorschlag! ^^:thumbup:

    Du meinst wie z.b. die (Renn)radfahrer, die mit 30-70km/h über öffentliche Radwege und Straßen fahren? :)

    Oder Smombies, die blind überall hin springen… ;)

    Das Tempolimit alleine hindert ja noch keinen, schneller zu rasen. Selbst Kontrollen und Strafen sind kein ausreichendes Mittel zur Temporeduktion. Es gibt trotzdem immer irgendwelche Verhaltenskreativlinge, die Andere in Gefahr bringen und bis zum Maximum aufs Gaspedal drücken.

    Afaik bleibt der normal bestehen. Es kann allerdings sein, dass er z.B. nach einem Jahr Inaktivität gelöscht wird. Notfalls halt beim Support nachfragen, wie das im Detail gehandhabt wird.