Alternative zur ganzzahligen Division bei z.B. Anzeige "Freier Speicherplatz"
-
Ist definitiv ein Luxusproblem meinerseits:
bei meinem NAS ist der freie Speicherplatz jüngst unter 2TB gefallen.
MV nutzt eine Drittanbieterbibliohek zur Anzeige des freien Speicherplatz, welche rein auf ganzzahliger Division beruht:org.apache.commons.io.FileUtils.byteCountToDisplaySize(usableSpace)
Das bewirkt, dass bei mir derzeit ca 900 GB an Rest nach Ganzzahliger Division durch die “Terabyte-Konstante” nicht angezeigt werden. Sprich, MV zeigt durch diese Funktion an, ich hätte 1 TB freien Speicherplatz. Da ganzzahlige Division ja salopp gesagt “abrundet”, ist das mathematisch völlig korrekt. Nur weiß ich nicht, ob ich schon so weit bin, 900 GB als “nicht der Rede wert” anzusehen.
Ich hab mal kurz Kommentare zu dieser Runderei gelesen
https://issues.apache.org/jira/browse/IO-226
und dort wird verwiesen auf
https://issues.apache.org/jira/browse/IO-373
wo u.a. “Sammy” eine Ersatzfunktion eingestellt hat, welche immer drei Ziffern anzeigt.
Also
xxx oder
xx.x oder
x.xx(Dass in seinem Code BigDecimal.ROUND_DOWN zum Einsatz kommt, was seit Java 9 als deprecated markiert wurde, sei mal dahingestellt, aber das ließe sich lösen)
Ich hab in meinem ausgecheckten Code einfach mal das o.g. Ersatztool überall eingebaut statt der org.apache.commons.io Version und bei mir sieht das dann so aus:
Ich kann auch damit leben, mir MV selbst zu bauen, so lang das noch möglich ist.
Wollte einfach mal diesen Ansatz zu einemLuxusproblem zeigen. -
@rubikon mach doch Mal einen Pull request fertig dann kann ich mir das ansehen und ggf offiziell einbauen
-
@DerReisende77 ok. ich lese mich mal in git ein. Hatte bis auf das Auschecken noch keinen Kontakt damit. Ist vielleicht eh mal Zeit für mich zu schauen, wie man mit git arbeitet. - bisschen Geduld, bitte.
-
@rubikon GitHub Pull Request Doku
-
@DerReisende77 sagte in Alternative zur ganzzahligen Division bei z.B. Anzeige "Freier Speicherplatz":
@rubikon mach doch Mal einen Pull request fertig
Ich glaub, ich komm so ganz langsam in die Grundlagen von git rein.
Pull Request ist wunschgemäß erstellt.Hab den o.g. Code aus dem Apache Forum nochmal angeschaut und bissl aufgeräumt.
Aber, das Ding rundet im Gegensatz zur derzeit verwendeten Funtion nicht grundsätzlich ab. Beispiel
Hat man 1,995 GiB frei,
dann gibt die Funktion zurück “2 GB” (gemeint sind 2.00 GiB – aber … geschenkt. )
Will man jetzt einen Film mit 1,995001 GiB speichern,
dann sieht es so aus also hätte man genug Platz (1,995001 < 2,00)
ist aber falsch weil die angezeigten “2 GB” in dem Fall aufgerundet sind und 1,995 < 1,995001.Wenn das stört, kann man aber im ByteUnitUtil die Rundungsmethode umstellen. Ich weiß schlichtweg nicht, wie die Datei-Explorer der verschiedenen Betriebssysteme hier runden. Da ein Unit Test mit Grenzfällen dabei war, hab ich einfach die vom Hinweisgeber verwendete Rundungsmethode beibehalten.
Zum Verwenden “meines” (halb geräuberten, halb selbst geschraubten) Tools:
an den entsprechenden Stellen im Code Aufrufe von
org.apache.commons.io.FileUtils.byteCountToDisplaySize
ersetzen durch
mediathek.tool.ByteUnitUtil.byteCountToDisplaySize -
Hab inzwischen nochmal getestet und der aktuelle Code hat eine Inkonsistenz.
Ich ermittle das Einheitenpräfix durch eine separate Rechnung mit einer anderen Rundungsvorschrift.
Der Effekt ist, dass knapp unterhalb des nächsten Einheitenpräfix komische Anzeigen kommen.
So werden 1048575 Byte (=2^10 - 1) als 1024 kB angezeigt und nicht als 1 MB.
Der Fall war leider im ursprünglichen Test nicht mir drin.Weil das Problem durch die o.g. Rundungsvorschrift “aufrunden” entsteht,
ist meine Frage, ob der Eingangswert
1048575 Byte
als 1023 kB (abgerundet auf volle kB) oder
als 1 MB (aufgerundet ab 0,995 MB)
angezeigt werden soll oder ob’s tatsächlich bei den momentanen seltsamen 1024 kB bleiben soll.Bei Bedarf würd ich meinen Code dann entsprechend anpassen, etc.
-
Das Schöne, an dem Versuch, das Verhalten von Datei-Explorern zu imitieren ist die Erkenntnis, dass es verschie… :zipper-mouth_face:
Was ich nun habe ist Erkenntnis über zwei solche Rundungsmethoden und Code, der eines davon imitiert:
nie mehr als 3 Stellen insgesamt, immer abrunden:
0 bytes
1 bytes …
999 bytes
0.97 kB (für 1000 bytes) …
0.99 kB (für 1023 bytes)
1 kB (für 1024 bytes)
…
999 YB (1000 * 2^80 - 1 bytes)
1000 YB (nur für Personen mit vielen Festplatten relevant :grinning_face_with_smiling_eyes: )Eine andere Verhaltensweise (Datei-Explorer “Dolphin” von Debian Linux)
- vor dem Komma bis zu 4 Stellen
- immer 1 Nachkommastelle
- z.B. Anzeige “1024,1 MB”
…find ich persönlich weniger ausgewogen.
Vom Mathe- und Physikunterricht in der Schule her gefällt mir die Variante “immer 3 Stellen” gut, und “immer abrunden” erscheint mir in dem Fall sinnvoll.
Dass die Anzeige nicht MB, GB oder TB sondern MiB, GiB bzw. TiB lauten müsste (und wie Linux es auch macht, aber Windows nicht und auch die in MV eingesetzte Funktion nicht)… da bin ich offen und kann mit den “falschen” Präfixen leben.
Wenn’s dazu noch Fragen geben sollte, gerne.
Ansonsten, wie gesagt, Luxusproblem. Und ich hab wenigstens mal nen kleinen git-workshop gemacht und einen lustigen Vortrag von Linus bei Google über Quellcodeverwaltungssysteme gehört :smiling_face_with_sunglasses: -
@rubikon ich schau mir das Montag Abend an. Bin vorher leider verhindert
-
@DerReisende77 fühl Dich bitte nicht gehetzt. Ich hatte mich nur selber bei eigenen Fehler ertappt, und das hab ich lieber selber korrigiert als von anderen drauf hingewiesen zu werden. Drum meine vielen Antworten von mir an mich selbst :winking_face:
-
Um mir den freien Speicherplatz meiner Festplattenrekorder anzuzeigen, habe ich 2017 Xavers Tool aus der Klasse MVFilmSize
/** * Convert a byte count into a human readable string. * * @param bytes The number of bytes to convert. * @param si Use International System of Units (SI)? * @return The string representation */ public static String humanReadableByteCount(final long bytes, final boolean si) { final int unit = si ? 1000 : 1024; if (bytes < unit) { return bytes + " B"; } final int exp = (int) (Math.log(bytes) / Math.log(unit)); final String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp - 1) + (si ? "" : "i"); return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre); }an meine Vorstellungen angepasst, wobei diese durch die ganzzahligen Angaben von Diskpart beeinflusst worden waren:
public static String humanReadableByteCount( final long bytes, final boolean si ) { final int max = 9999; // 9999 oder 8191 /*/ Diskpart zeigt Partitionsgrößen und Offsets ganzzahlig an MiB von 8 bis 8191 GiB von 8 (8192 MiB) bis 8191? //*/ final int unit = si ? 1000 : 1024; if ( bytes <= max ) { return bytes + " B"; } int index = -1; long b = bytes; while ( b > max ) { b /= unit; index++; } final char pre = ( si ? "kMGTPE" : "KMGTPE" ).charAt( index ); return String.format( "%d %s%sB", b, pre, si ? "" : "i" ); } -
ok. Danke für den Vorschlag.
Ich halt mal Rundungsfehler zwischen tatsächlichem freien Speicherplatz und Anzeige fest:die derzeit verwendete apache commons io Funktion: bis zu 50% Rundungsfehler
(Beispiel: tatsächlich 2 TiB minus 1 Zuordnungseinheit frei ->Anzeige “1 TB frei”(zusätzlicher Fehler: vermischt SI Schreibweise mit IEC Größen –
andererseits sind mMn die Einheiten MiB, GiB, TiB viel weniger Menschen bekannt als MB, GB, TB)Windows-Explorer : “Fließkommazahlen insgesamt 3 gültige Ziffern”: bis zu 1% Rundungsfehler
(Beispiel: tatsächlich 2 TiB minus 1 Zuordnungseinheit frei ->Anzeige “1,99 TB frei”
(Anzeige “1,99 TiB frei” ist verhandelbar)Diskpart (1-4 stellige ganzzahlige Anzeige): bis zu 12,5% * Rundungsfehler (* max = 8192)
(Beispiel: tatsächlich 9 TiB minus 1 Zuordnungseinheit frei ->Anzeige “8 TiB frei”bis zu 10% * Rundungsfehler (* max = 9999)
(Beispiel: tatsächlich 11 TiB minus 1 Zuordnungseinheit frei ->Anzeige “10 TiB frei” -
@rubikon Habe deinen Pull request gerade in den develop branch integriert. Er wird also in 13.5 verwendet werden
-
@DerReisende77 ok, gerne.
Falls Ihr Anpassungswünsche habt in Sachen (binäre) IEC Präfixe und (dezimale) SI Präfixe oder zur Anzeige (Anzahl Stellen, ganzzahlig/fließkomma, Präfixname, …) weil mein Tool ja den Windows-Explorer imitiert und damit auf Linux und Mac komische so nicht unbedingt gewünschte Dinge anzeigt, schreibt mir … -
@rubikon also auf dem Mac entspricht die Anzeige dem was die posix Tools vermelden. Und mein NAS meldet nun 17,4TB statt 17TB freien Speicher was der Wahrheit sehr nahe kommt. Von daher passt das.
