Nein, ich habe gesehen, dass beid Zips genau gleich groß sind und habe daraufhin mit diff verglichen
Da kann man dann ziemlich sicher sein, dass es "dieselben" sind. Alles andere hätte mich auch überrascht
QTS 5.1.6.2722 build 20240402 released
-
- ARM + X86
- QTS
- Mavalok2
- Unerledigt
-
-
Und was ist mit diff?
-
Die Dateigröße sagt da nichts zuverlässiges aus, außer, dass es wieder eine ähnlich Datenmengen ist
Nein, die GLEICHE Datenmenge, sonst wär ja die Summe der Zeichen x><y. Man kann auch den Inhalt (Hex-Code) vergleichen mit frei zugänglichen Mitteln. Davon abgesehen: Den Entwickler möchte ich sehen, der nach einer Änderung die gleiche Datenlänge im Programm hinkriegt.
Im Nachhinein: Ich weiß nicht, wie duke-f vergleicht, aber mit den WIndowsmitteln, die ich verwendet habe, kriegt man das aufs Byte genau heraus
Aber klar, am einfachsten ist der Hashwert
-
Ich schrieb doch wiederholt: Mit diff
-
Nein, die GLEICHE Datenmenge, sonst wär ja die Summe der Zeichen x><y.
Dann müsstest Du aber min. bis aufs Bit hinunter und nicht nur Kilobyte vergleichen. So ist es, als würdest Du ein Skirennen nur mit Minuten messen.
Ich schrieb doch wiederholt: Mit diff
Lass mal die "Erwachsenen" streiten.
Zu diff kann ich jetzt nichts sagen, verwende ich nicht. Müsste aber wahrscheinlich auch funktionieren. Nur rein über die Dateigröße in KB wäre mir jetzt zu ungenau. -
Hab jetzt mal die MD5 Werte für beide Dateien for Ausfall und danach verglichen, sie sind identisch.
-
Dann müsstest Du aber min. bis aufs Bit hinunter und nicht nur Kilobyte vergleichen
Ich vergleiche sicherlich keine KByte, sondern tatsächlich jedes Bit im Byte. Und "min." ist ja auch verkehrt, weil weiter auflösen als Bit geht ja momentan für uns noch nicht, oder?
QBit?Ich habe nun nicht nachgeschaut, wie groß die FW ist. Aber HEX-Dateien zu vergleichen ist wahrlich kein "HEX"-enwerk. Da springt der Cursor sogar an die Stelle, wo Unterschiede sind und markiert die rot
Scheiss was auf den HASH-Wert
-
Lass mal die "Erwachsenen" streiten.
Na gut, lass ich mal die „Erwachsenen“ weiter Hasch mich spielen, wenn sie die Selbstbestätigung so dringend brauchen.
Und für die, die nicht googeln können, es aber doch wissen wollen: diff ist uraltes Unix und macht genau das: Den Inhalt zweier Dateien vergleichen. Und das ganz ohne Hash.
-
Es gibt doch eine Änderung, kann auch Zufall sein.
Seitdem der Download wieder eingestellt wurde, erkennen auch meine NAS (NAS + QFinder), dass es eine neue Firmware gibt.
Auf meinem neuen Testnas soeben installiert. Sieht gut aus.
Hinweis:
QNAP hat der Fehler mit den drehenden SSD, wie in den Release Notes beschrieben, behoben.
-
Bei dem was da gerade abgeht mit der 5.1.6 verzichte ich zunächst mal auf ein Update meiner beiden NAS. Die alte Version läuft ja ...
Seit heute morgen will auch das TS-431P2 bei mir ein FW-Update. Warte trotzdem, vllt.auf 5.1.7 oder sogar 5.2...
-
Mein TS-364 von QTS 5.1.5.2679 upgedatet. Sieht gut aus.
-
Habe gestern auch meine produktiven NAS TS-653A und TS-451+ aktualisiert.
Derzeit läuft alles, mal abwarten.
-
Habt ihr mal die Lese-Performance per SMB getestet? Irgend welche Auffälligkeiten?
-
Bisher nicht. Die zweite 5.1.5 hat sich teilweise eine Gedenkminute beim Lesen von Verzeichnissen via SMB gegönnt.
Dies konnte ich bislang noch nicht feststellen, aber die Zeit ist dazu wohl noch zu kurz.
-
Nicht an allem Unglück ist Qnap Schuld.
Gestern nach dem Update ging nichts mehr. Die Freigaben fehlten, die Apps wurden nicht gestartet, nicht mal das Hintergrundbild wurde geladen. Ich wollte schon zurück auf die 5.1.5, hab's aber zum Glück doch nicht gemacht, sondern mir die Sache näher angeschaut. Ergebnis war, auf Grund einer Netzstörung bei Vodafone vor zwei Wochen und Zurücksetzen der Fritzbox war die Konfiguration letzterer fehlerhaft, so dass mein Autorun-Skript nicht mehr an die Verzeichnisse mit den Schlüsseldateien zum Entsperren der Volumes kam. Dieser Fehler wäre also bei jedem Neustart des NAS aufgetreten.
Das Update selbst auf 5.1.6 war dann problemlos, und bisher läuft alles, was ich nutze. Auf TS-877.
-
Habt ihr mal die Lese-Performance per SMB getestet?
Ich habe jetzt mal sowohl die Lese- wie auch die Schreibperformance getestet, von / zu einem Windows PC mittels 1 GBE Link auf / von einer SSD und muß sagen, ich bin schwer beeindruckt:
Die Leseperformance von einem Volume-verschlüsselten Vol liegt bei kontant 113 MB/s und lastet damit den 1 GBE Link voll aus.
Aber auch bei der Schreibperformance auf das Volume-verschlüsselte Vol erreiche ich bei meinem 7 Jahre alten NAS mit Celeron-CPU wieder konstant ca. 106 MB/s, da hat sich eine Menge getan.
Manchmal macht QNAP auch was richtig!
-
Upgrade von TS-451+ von QTS 5.1.5.2679 build 20240219 auf QTS 5.1.6.2722 build 20240402 lief heute problemlos durch; alles läuft wie vorher - die Lese- und Schreibperformance auf SMB/Windows-Drives habe ich nicht getestet, scheint alles OK zu sein.
-
Läuft alles, bisher keine Auffälligkeiten in meiner QNAP Sammlung
1x 231p,
1x 431p,
2x 431k
-
Na dann bin ich ja mal gespannt ob die Spam-Meldungen nun behoben sind:
Mod: Zitat ohne Quellenangabe ... korrigiert!
Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzenFixed an issue in Notification Center where an alert notification rule created from an existing event log might fail to apply as expected if the keyword filters in the rule were too long.
Ich hatte bei mir ja die RAID-Bereinigung von Hand mit in die Benachrichtigungen aufgenommen. Und der Nachrichtentext ist bei der Benachrichtigung doch schon etwas länger...
Bspw.:
Code[Speicher & Snapshots] Bereinigung der RAID-Gruppe "2" gestartet. Speicherpool: 1, Priorität: Default. [Speicher & Snapshots] Bereinigung der RAID-Gruppe "2" beendet. Speicherpool: 1, Reparierte Blöcke:0.Ich überlege ob man das abkürzen könnte, bspw.:
Code[Speicher & Snapshots] Bereinigung der RAID-Gruppe*und dann sind beide Meldungen mit abgefrühstückt...
