Beiträge von KB19

    Wäre auch ein Sicherheits-GAU, weil dann (wenn es funktionieren würde) JEDER User ALLE Dateien von anderen Usern einlesen könnte. Das das nicht sinnvoll ist, sollte logisch sein.

    Wenn Du die Funktion brauchst, ohne Umweg über PHP & Co., wird es max. bei einem (managed) vServer klappen. Aber auch dort würde ich eher davon abraten. Man hebelt damit leicht Sicherheitsfunktionen aus.

    Eventuell findest Du eine performantere Lösung über SSH (Bash & Co.) oder, wenn es über HTTP sein muss, halt exec() u.ä. Funktionen. Wenn Du uns ein Beispiel Deiner CSV-Daten zeigen würdest, könnte man sicher etwas basteln oder eine fertige Lösung im Internet finden. :)

    mainziman Ich kenne bzw. habe nur einen RS 500 SSD G8 a1 BF [2018] (2 Cores; 4 GB RAM; 30 GB SSD; 12 Monate MVL) um € 5,03 (AT). Den gab es bei irgendeiner Aktion afaik aber auch mal um ein paar Cent günstiger, allerdings nicht um einen vollen Euro.

    ZeroSSL? Höre ich heute zum ersten Mal :/

    Soweit ich das sehe bekommt man dort nicht einmal Wildcard-Zertifikate, wenn man nicht zahlt?

    Muss ich mir trotzdem mal notieren, ausprobieren tut nicht weh… ^^

    Für mich völlig unverständlich, weil sowas normalerweise nicht lange dauert.

    Das würde ich jetzt so pauschal nicht sagen. Mein letzter data/updater-* Ordner hat stolze 655 MB und besteht aus 32.000 Dateien, wobei das sicherlich noch gar kein Extrembeispiel ist. Je nach System, den eingestellten Limits und der Größe aller beteiligten Caches (OS/RAID/Speichermedium) wird das durchaus länger als ein paar Sekunden dauern.

    Bei meinem WH8k läuft das zwar zum Glück nicht in ein Timeout, aber da dauert es auch einige Zeit. Über SSH würde das Kopieren dieses Ordners aktuell ca. 13 Sekunden dauern. Wenn man aber bedenkt, dass es beim Updater über PHP läuft und dort sicherlich noch viel mehr vergleichen bzw. beachtet werden muss, wären auch 30-60 Sekunden je nach Systemauslastung nicht verwunderlich. (Wie man die 180 Sekunden erreicht ist eine andere Frage.)

    Edit: Ich merke gerade erst, dass man das bei Verwendung des CLI-Updaters angeblich endlich deaktivieren kann. Beim webbasierten Updater macht er es jedoch weiterhin.

    Siehe: https://github.com/nextcloud/updater/pull/292 (--no-backup)

    Wenn du einen neuen Snapshot erstellst, während noch ein vorheriger vorhanden ist, baut der neue Snapshot auf dem alten auf. Wenn du dann den älteren Snapshot löschst, wird das Delta in den nachfolgenden integriert, in der Darstellung sollten dann alle Snapshots eine Ebene nach links wandern. Ist meiner Meinung nach also korrekt, so wie es dargestellt wird.

    Das ist mir schon klar. Ich meinte allerdings den untersten Eintrag. Warum steht der mittendrinn völlig alleine da? Das ergibt für mich keinen Sinn.

    Ist aber mittlerweile egal. Trotz löschen aller Snapshots wurde der verbrauchte Speicherplatz nicht mehr weniger. Ich musste dann eine Speicheroptimierung durchführen.

    Zusätzlich spinnt seit ein paar Tage einer der DNS Server sporadisch:

    Code
    Resolver 46.38.252.230 is unreachable

    kann das jemand auch bestätigen?

    Offenbar ja. Gerade zufällig mehrfach in den Logs von letzter Woche entdeckt: cURL Error 28 - Resolving timed out after 3000 milliseconds

    Code
    Mar 20 04:02:27
    Mar 24 18:56:29
    Mar 25 23:10:05
    Mar 26 00:13:02

    (Das Timeout ist bei dieser Anwendung absichtlich so niedrig gesetzt.)

    Kann mir mal jemand erklären, warum man bei einem Befehl unter Android (LineageOS 16.0), den man mit Termux (Widget) als Root-User ausführen möchte, zwei mal su braucht? :/

    Andernfalls hagelt es z.B. bei am/pm/usw. die bekannten "Failed transaction" Fehler. Ist ja ein netter Workaround, aber auf die Idee muss man erst einmal kommen… (Danke GitHub & Reddit! ^^)

    Normalerweise führe ich am Handy nie solche Befehle aus, immer nur über die ADB-Shell. Vielleicht ist dieses Verhalten eh allgemein bekannt, für mich war das aber neu.

    das mit 'fast', 'knapp' od. 'beinahe' ist auch etas spezifisches

    Fast heißt halt, dass es noch keine ernstzunehmende Verbrennung zweiten Grades war. :S

    (Und solche Verbrennungen sind besonders an den Fingerkuppen extrem unschön, ich spreche da aus Erfahrung. Daran war aber kein USB-Stick sondern ein Lagerfeuer schuld.)

    pasted-from-clipboard.png

    wie klein doch USB-Datenträger sein können ;)

    Ist das ein Delock 54072? Wird der (unter Last) eigentlich auch so extrem warm?

    Der letzte Stick in einem ähnlichen Design (Kingston DTSE9H), aber wesentlich größer, wurde selbst im "Leerlauf" sehr warm. Da hatte ich schon Angst, dass der irgendwann mal abfackelt. :D

    (Und den will ich irgendwann endlich durch genau diesen Delock-Stick mit 128GB ersetzen.)