[ololoe]

Originally Posted by oEFLKQzikCqw

Du beschreibst Sparsefiles. Schaue dir doch mal die Eigenschaften einer mit µTorent heruntergeladenen unfertigen Datei an, insbesondere die Größe auf dem Datenträger. Die dürfte kleiner als die Größe der Datei sein. Das ist nur bei Nutzung von Sparsedateien oder der NTFS-Komprimierung der Fall.

Ich werde es mir bei der nächsten Gelegenheit anschauen, aber das freie Platz wurde um die Grösse der Dateien reduziert, und als inhalt hatten die Dateien die früher gelöschte Dateien (ich habe einmal ein Video gestartet und es lief stattdessen ein Video den ich vor kurzem gelöscht habe). Daher glaube ich, dass ich recht habe.

Originally Posted by oEFLKQzikCqw

Ja die Preise für diese Dinger sind meist ziemlich happig, es sei denn man erwischt ein Schnäppchen.

Es passt zwar nicht jedes Laufwerk in jedes Notebook, aber es ist auch nicht so, das jedes Laufwerk nur in ein einziges ganz bestimmtes Notebook passt, so dass der Rahmen durchaus in anderen Notebooks passen könnte.

Wie sieht die Kompabilität aus? Gibt es Standarts für DVD Laufwerksanschlüsse für Notebooks?
Was kosten sie? 15 oder sogar 20 euro vs. 30 euro unterschied zwischen 128 und 256 Gb. Übrigens, warum wurden die SSDs nach einem Jahr nicht billiger?

[Jiaz]

JD nutzt SparseFiles. Sprich Windows zeigt sofort die *fertige* Größe an, belegt aber nur die *real* genutzte Größe . Fsutils und Dateieigenschaften zeigen das.

[Jiaz]

@ololoe

[ololoe]

Ihr seid wirklich die erste von Download Managers, die auf die Idee kommen Ordner zu löschen, die ihr selber sogar nicht angelegt habt.

[ololoe]

Originally Posted by Jiaz

JD nutzt SparseFiles. Sprich Windows zeigt sofort die *fertige* Größe an, belegt aber nur die *real* genutzte Größe . Fsutils und Dateieigenschaften zeigen das.

Und wie wird das umgesetzt? Führt das zu Fragmentierung?
Gibt es die Option, gleich die volle Grösse zu belegen?

[Jiaz]

Originally Posted by ololoe

Ihr seid wirklich die erste von Download Managers, die auf die Idee kommen Ordner zu löschen, die ihr selber sogar nicht angelegt habt.

JD löscht den Ordner nur falls es nicht der Default Ordner ist und er danach leer ist. Aber werde das demnächst beheben

[Jiaz]

Originally Posted by ololoe

Und wie wird das umgesetzt? Führt das zu Fragmentierung?
Gibt es die Option, gleich die volle Grösse zu belegen?

Inwiefern dabei Fragmentierung entsteht ist dem OS/Filesystem überlassen. Sparse bedeutet nur das leere Bereiche nicht "zwangsgefüllt" werden müssen.
Auch ohne Sparse kann es zu Fragmentierung kommen.

[ololoe]

Originally Posted by Jiaz

JD löscht den Ordner nur falls es nicht der Default Ordner ist und er danach leer ist. Aber werde das demnächst beheben

Wonach? Och, ich spüre dass ich gleich den nächsten Ban kriege.

Originally Posted by Jiaz

Inwiefern dabei Fragmentierung entsteht ist dem OS/Filesystem überlassen. Sparse bedeutet nur das leere Bereiche nicht "zwangsgefüllt" werden müssen.
Auch ohne Sparse kann es zu Fragmentierung kommen.

Beim Sparse-Dateien gibt es aber die Fragmentierung immer, auch wenn genug unfragmentiertes Platz vorhanden ist.

[Jiaz]

Nein, warum sollte es nen Ban geben? Das mit dem Ordner werd ich bald angehen. JD legt einfach ne Info Datei in den Ordner mit ab, damit JD weiß das der Ordner erstellt wurde und wieder gelöscht werden darf. Das mit dem Ordner löschen war übrigens schon immer so und wurde damals (vor vielen Jahren) so gewünscht und du bist der erste dem es negativ auffällt. Aber ist auch klar, wenn es ein Link ist Wird behoben.

Sparse Files fragmentieren genauso viel/wenig wie normale Files.
Wenn ich ein SparseFile öffne und sequentiell reinschreibe und keine andere IO Last existiert, dann gibts im Idealfall auch keine Fragmentierung.
Genauso kann ein NON Sparse File fragmentieren, wenn gleichzeitig weitere Dateien erstellt/geschrieben/gelöscht werden.
Und ob ein Sparse File fragmentiert oder nicht liegt eben auch in der Hand des Dateisystems.




Ohne Sparse Files gibts im aktuellen DownloadSystem eben Probleme mit großen Dateien und Multichunks. Der nächste Downloadcore an dem ich gerade arbeite umgeht das Problem indem die Datei von Vorne->nach Hinten geladen wird und nicht in gleichgroße Stücke aufgeteilt wird. Ein Jump ans Ende einer x GByte Datei dauert eben mal ein paar Sekunden/Minuten (ohne Sparse).

[oEFLKQzikCqw]

Originally Posted by Jiaz

Der nächste Downloadcore an dem ich gerade arbeite umgeht das Problem indem die Datei von Vorne->nach Hinten geladen wird und nicht in gleichgroße Stücke aufgeteilt wird. Ein Jump ans Ende einer x GByte Datei dauert eben mal ein paar Sekunden/Minuten (ohne Sparse).

Das bedeutet dann, dass die Datei in vielen kleinen Chunks (aber immer nur die eingestellte Anzahl gleichzeitig) geladen wird und dass es etwas mehr Overhead gibt.

[ololoe]

Originally Posted by Jiaz

Nein, warum sollte es nen Ban geben?

Jedes mal wo ich über Qualität rede, vergesse ich wieder dass sie hier nicht vorhanden ist und rege mich wieder darüber auf statt zu nutzen was halt funktioniert.

Es geht hier nicht nur um Links, ich kann einfach nicht eure Logik nicht nachvollziehen. Du hast immer noch nicht gesagt wonach Ordner gelöscht werden.

Ohne Sparse Files gibts im aktuellen DownloadSystem eben Probleme mit großen Dateien und Multichunks.

Hast du mal geschaut wie die andere Download Manager funktionieren? Könnte nützlich sein

Der nächste Downloadcore an dem ich gerade arbeite umgeht das Problem indem die Datei von Vorne->nach Hinten geladen wird und nicht in gleichgroße Stücke aufgeteilt wird.

Oooh das ist die Feature auf die ich seit Jahren warte dass jemand sie implementiert. Das wird gebraucht wenn man eine Videodatei lädt und geschwindigkeit mit 1 Verbindung nicht ausreicht für pausenloses Streaming, mit mehreren Verbindungen aber schon.

[Jiaz]

Andre DownloadManager haben die selben Probleme
Entweder man benutzt
1.) Sparse, schnellen Zugriff auf egal wohin
2.) Pre-Allocation, unter Umständen lange StartZeit, macht keine Freude auf ne NAS eine 8GB Datei zu erstellen oder gar noch größer. Und ja, das Problem betrifft primär große Dateien und langsame Medien
3.) Datei von Vorne nach Hinten laden um eine Pre-Allocation zu verhindern und dennoch Chunks nutzen zu können

Löschen von Ordner: Habe ich bereits geschrieben
"JD löscht den Ordner nur falls es nicht der Default Ordner ist und er danach leer ist."
Handelt es sich um den Parent der Datei NICHT um den Default-Download-Ordner und ist dieser nach dem Löschen der Datei leer, so wird auch der Ordner selbst gelöscht.

DownloadCore -> Der kann noch vieles mehr. Zb on the Fly Chunks dazu/wegnehmen. Der aktuelle kann nur statische Chunks und eben auch die Probleme mit den großen Files, siehe Punkt 2.

Aber dennoch gibts keinen Ban, wenn du begründete Punkte aufweist und ich sie auch verstehe und verbessern/beheben werde.

[ololoe]

Habe gerade getestet

f=file(r'x:\_test\asd','w')
f.seek(int(1e9))
f.write('\0')
f.close()

Die Datei auf einem NAS wurde sofort erstellt und besteht aus nullen, warscheinlich unterstützt NAS selbst Sparse-Dateien. Dasselbe für externe NTFS Festplatte. Wo kann man sehen ob es Sparse-Dateien sind oder nicht?

Dateien sequentiell laden um problemen von viel schnelleren Festplatten zu losen ist natürlich ein gewaltiger Overkill. Wie Base64 oben sagte da gibt es ein Overhead gegenüber normalen Vorgehen.

"JD löscht den Ordner nur falls es nicht der Default Ordner ist und er danach leer ist."
Handelt es sich um den Parent der Datei NICHT um den Default-Download-Ordner und ist dieser nach dem Löschen der Datei leer, so wird auch der Ordner selbst gelöscht.

Wonach? Wer löscht die Datei?

[Jiaz]

Wenn es ne normale NAS mit Linux unterbau ist, dann ist es in 99% der Fälle EXT4 und Sparse per default Bei NTFS wird dein obiger Call auch schnell sein, da by default compress an ist und zig tausend nullen auch schnell geschrieben sind.

JD, sofern JDownloader die fertigen Downloads löschen soll. Zb nach dem Entpacken der TeilArchive, diese löschen und dann den leeren DownloadOrdner löschen

[ololoe]

Also ich glaube ich hatte gar keine Archiven/gesplitteten Dateien und Archive Auspacken ist ausgeschaltet. Das muss was anderes gewesen sein.

[Jiaz]

Das ist die einzige Stelle an der JDownloader den Download Ordner löscht

[ololoe]

Archive Auspacken ist ausgeschaltet

^^

[Jiaz]

Ich kann nur sagen was JDownloader macht. JD löscht den Ordner nur wenn die Dateien entfernt werden.

[ololoe]

Ich kann auch nur sagen was passiert ist: das Link wurde entfernt und stattdessen ein Ordner angelegt. Entpacker ist aus. Soll ich ein Screenshot beilegen?

[Jiaz]

Ist es der DownloadOrdner? Oder um welchen Ordner hat es sich gehandelt? Ich glaub dir das, kann es nur nicht nachvollziehen oder finden, wo das im JDowloader passieren sollte.