(teil-gelöst) verkorksten wget d/l beschneiden

[michaa7]

Ein wget d/l wurde abgebrochen (wget-log.1)
der d/l des file wurde wieder aufgenommen (wget-log.3)
der d7l des files wurde versehntlich nochmals aufgenommen (wget-log.4)

Ich verwende hier in der beschreibeung die tatsächlichen wget-log.# um nicht noch mehr durcheinander zu haben (wget-log.2 ist ein anderer d/l, der nicht zur sache tut).

Alle d/l_s habe ich wieder gekillt, weil der verdoppelte d/l ja ein gehäckseltes file erzeugt, ab der doppelten wiederaufnahme.

Was ich tuen möchte:
Den partiellen d/l zurückschneiden auf die länge von (wget-log.1) , vielleicht besser auf genau die länge der letzten vollen zeile des logs (grün), welches ich dann entsprechend ändern müßte(rot):

$ tail -n 5 wget-log.1
289750K .......... .......... .......... .......... .......... 88% 31,7K 71m4s
289800K .......... .......... .......... .......... .......... 88% 20,8K 70m48s
289850K .......... .......... .......... .......... .......... 88% 4,96K 70m58s
289900K .......... .......... .......... .......... .......... 88% 16,3K 70m45s
289950K .......... ..........

Mit welchem Programm liese sich das file mit diesen angaben entsprechend kürzen. Ist die angabe 289900K unmisverständlich/exakt?

[Cae]

Dateien zurechtschneiden geht mit truncate(1):

Code: Alles auswählen

$ truncate -s 289900K download

und das sollte schon exakt die genannte Groesse sein. Einziger Punkt koennte der Unterschied zwischen k (Basis 1000) und K (Basis 1024) sein, d.h. "1K" ist groesser als 1k.

Gruss Cae

[michaa7]

Danke soweit.

Ja, truncate regelt das eindeutig ob K oder KB gemeint ist. Wget diesem alten bugreport nach nicht.

Allerdings frage ich mich ob das überhaupt von belang ist. Wget braucht doch zur wiederaufnahme das alte log gar nicht. Dort wo abgeschnitten wurde gehts weiter. Die frage wäre ehr ob es soetwas wie einen unsauberen schnittrand ergibt, wenn ich auf basis einer falschen grundgröße schneide, und dies dann wget durcheinanderbringt?

EDIT:

Endweder es aber richtig, oder es ist einfach egal. d/l ist nun komplett.

Mercie nochmals.

Edit2:
Leider war an der wiederaufnahmestelle dann doch ein knoten im file. Das spricht irgendwie doch für unsaubere schnittränder.

EDIT3:
Ich habe das file jetzt nochmals gekürzt, noch weiter vorne, dabei statt K jedoch KB:

Code: Alles auswählen

[truncate -s 280000KB file 

wget nimmt diesen d/l so auf:

[ überspringe 273400K ]
273400K ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,... .......... 83% 44,9K 82m22s

Ich hatte mal irgendwo gelesen, dass wget bei abgebrochenen d/l am ende etwas abschneidet, hab das aber nicht mehr gefunden und in den man-pages steht nichts dazu.

Der unterschied könnte also durch abschneiden entstanden sein, aber warum gerade 6600K?xy ? Eine merkwürdige zahl. Oder es gibt da irgendeien diskrepanz zwischen altem und neuen standard für binäreinheiten.

Kann das jemand aufdröseln? Ich beende eben nochmals den d/l um festzustellen ob er jetzt knotenfrei zu ende kommt.