BOM Release Wrapper

[XcalibuR]

Hmm .. koennte man das nicht ganz unabhaengig von Verzeichnissen realisieren?

Beispiel: Ich entpacke immer nach Z:_incoming{artist} - {album}
Wenn ich sie getagged und benannt hab kommt das ganze meist nach x:---==[ MP3s ]==---{artist} - {album} und manches auch auf CD.
Heisst das, dass wenn ich eine RCI verwenden will die Dateien in z:_incoming... sein muessen? Koennte ich da nicht einfach ein Verzeichnis angeben?

[Feltzkrone]

Der Name des Verzeichnisses, in das entpackt wurde, wird nicht in der RCI Datei gespeichert. Stattdessen wird in dem Verzeichnis gesucht, in dem die RCI Datei vorhanden ist.

Wenn Du also alles nach Incoming entpackst (ich hoffe Du erstellst ein neues Unterverzeichnis pro Archiv), schiebst Du die entpackten Dateien (oder das Verzeichnis, das alle enthaelt) zusammen mit der RCI woanders hin. Zum Beispiel sogar auf eine gebrannte CD. Hauptsache ist nur, dass die RCI im gleichen Verzeichnis liegt, wie die einst entpackten Dateien.

Das Wiederherstellen laeuft so ab, dass erst die RCI-Datei eingelesen wird. Dabei wird eine Suchliste fuer alle Dateiteile erstellt, die NICHT mit in die RCI uebernommen wurden. Anschliessend werden ALLE Dateien im RCI-Verzeichnis inkl. Unterverzeichnisse daraufhin "gescannt", ob sie diese benoetigten Dateiteile enthalten. Fuer jeden gesuchten Teil ist ein 32-byte grosser Suchstring in der RCI-Datei abgelegt und zusaetzlich die CRC32 des kompletten Teils.

Wird ein Teil einer gescannten Datei identifiziert, dann merkt sich das Prog, welchem gesuchten Teil der gefundene entspricht und streicht diesen aus der Suchliste.

Zuguterletzt wird dann die urspruengliche RCA-Datei wiederhergestellt. Die Dateiinhalte werden dann entweder aus der RCI-Datei uebernommen (ID3-Tags und komplett uebernommene Dateien) oder aus der jeweils gefundenen Datei, die den gesuchten Block enthaelt.

Unter Umstaenden kann das ganze natuerlich sehr lange dauern, wenn viele Dateien gescannt werden, die gar nicht zu der RCI-Datei gehoeren. Das trifft z.B. dann zu, wenn man viele Archive blind ins gleiche Verzeichnis entpackt. Verhindern kann man das nicht, da ich das System bewusst so flexibel gestaltet habe. Ansonsten waere es nicht moeglich, die Dateien nach dem Entpacken frei nach Lust und Laune umzubenennen.

[XcalibuR]

Hauptsache ist nur, dass die RCI im gleichen Verzeichnis liegt, wie die einst entpackten Dateien.

okay, klasse. Da spricht ja dann nix dagegen, die Dinger zu trennen und spaeter, wenn man ein Archiv wiederherstellen will, vorher wieder zusammenschiebt

[Feltzkrone]

So, heute nacht bekomm ich das Prog definitiv fertig. Die Suchroutinen (mit das schwierigste) funktionieren einwandfrei, somit ist das Problem des Wiederherstellens praktisch geloest.

Jetzt muss ich noch das Re-Archivieren umsetzen (dauert schaetze ich 10 Minuten), danach die ID3-Tag-Erkennung beim Entpacken (ich plan mal ne halbe Stunde ein) und zu guterletzt nur noch ein paar Feinheiten, wie z.B., dass man Zielverzeichnis/Zieldateien per Browser auswaehlen kann.

Bevor dann morgen losgemeckert wird: Beim Scannen der Dateien fuer die Wiederherstellung gibt es keine Fortschrittsanzeige, d.h. bei grossen Dateien sieht es unter Umstaenden mal so aus, als haette sich das Prog aufgehangen. Es gibt keine Fortschrittsanzeige, weil die maximale Dauer fuer das Scannen einer Datei theoretisch bis unendlich gehen kann. Meiner Meinung nach dann lieber keine Anzeige als eine, die saumaessig ungenau ist.

[XcalibuR]

hm, kann man so nen Fortschrittsanzeigebalken nicht parametrisieren, also linkes Ende entspricht 0 bytes und rechtes Ende entspricht (Dateilaenge) bytes, und dann beim scann0rn einfach nach jeweils x gelesenen bytes ein bissl rumpfriemeln?

Und das von dem der gesagt hat, dass die Optik wurscht is

[Feltzkrone]

Naja, kleines Beispiel:

Ein Archiv hat 500 Dateien. Fuer's Wiederherstellen wird von jeder Datei die ersten 32 Bytes in der RCI-Datei gespeichert.

Beim Wiederherstellen klappert er nun alle Dateien im RCI-Verzeichnis ab, was im guenstigsten Fall 500 waeren. Die Gesamtdatenmenge waere auch bekannt (die Summe aller Dateigroessen).

Nur kann es jetzt so sein, dass sich mehrere entpackte Dateien dieselben ersten 32 Bytes teilen. Jedesmal, wenn beim Wiederherstellen in einer Datei die gewuenschten 32 Bytes gefunden werden, wird fuer eine entsprechende Datenmenge (koennen mehrere MB sein, je nach Datei) die CRC32 berechnet und daraufhin ueberprueft, ob sie mit der gesuchten CRC32 uebereinstimmt.

Angenommen, 250 Dateien haetten dieselben ersten 32 Bytes (welche jeweils nur am Anfang der Dateien auftauchen, sonst wird's noch schlimmer) und waeren alle 100 KB gross. Dann wuerden im schlechtesten Fall 250*250*100 KB ueberprueft. Im guenstigsten Fall aber nur 250*100 KB. Wie soll man also wissen, welcher Fall eintritt.

Nehmen wir mal an, wir waeren im zweiten Fall bei 100% angelangt. Wir haetten dann insgesamt 25000 KB geprueft.

Wenden wir diese 25000 KB auf den ersten Fall an, so waere diese Zahl verglichen mit der Gesamtmenge von insgesamt 6250000 KB gerade mal 0.4%!

Ich moechte jedenfalls keine Fortschrittsanzeige haben, die (nahe) 100% anzeigt und in Wirklichkeit gerade mal 0.4% abgearbeitet sind. Das waere dann so aehnlich wie die Setups von Microsoft...

[DaGrimOne]

Ich find's schon mehr als respektabel, das du dir ueberhaupt die Arbeit machst. Und als Belohnung wird dein Programmchen einen Ehrenplatz auf meiner Platte bekommen und ausfuehrlich getestet werden!

[Feltzkrone]

So, alles wichtige ist jetzt fertig, d.h. die ganze Kacke zur ID3-Tag Erkennung und das Wiederherstellen einer Datei lueppt jetzt perfekt. Man kann das Programm, so wie es jetzt ist, schon benutzen.

Was fehlt ist wie gesagt das Browsen nach anzulegenden Verzechnissen/Dateien und das Umsetzen des FileMode auf ReadOnly wenn's geht, ansonsten gibt's aerger mit schreibgeschuetzten Dateien. Ach ja, die Verknuepfung mit den Dateitypen sollte ich auch noch realisieren...

[Feltzkrone]

Fuer alle Interessierten hab ich jetzt die RCAM v1.00 beta im Angebot. Spielt damit herum, soviel ihr wollt, am Archivformat wird sich nichts mehr aendern, also macht ruhig auch schon Releases damit.

Kleine Zusammenfassung:
- Erkennung von ID3v1 und ID3v2 Tags beim Entpacken
- Dateitypen RCA und RCI werden mit dem Tool assoziiert
- Wiederherstellen der urspruenglichen Archivdatei (bitgenau)
- Wahlweise Sicherung von voraussichtlich spaeter geloeschten Dateien

<a href=http://feltzkrone.freezope.org/rcam100b.zip>rcam100b.zip</a> (326kb)

Bekannte Bugs und Plaene:
- Reservierter Speicher wird z.T. nicht freigegeben, was aber das OS beim Beenden des Tools erledigt, sprich, exzessives Benutzen des Tools in einem Lauf kann zu Instabilitaet fuehren
- Vor Dateiueberschreibungen wird noch nicht gewarnt
- Keine Moeglichkeit, nach fehlenden Dateien per Hand zu suchen

[Azathoth]

so, ich habs mal gesaugt und werds mal ueberpruefen.

kritik kommt ... wenn ich mal zeit hab

[Ludwig Hagen]

Das Packen geht recht langsam vor sich, und ca. jede Sekunde wird eine Pause von ca. einer Sekunde eingelegt. Die Systemauslastung von dem Teil liegt waehrend des Betriebs bei 99 %!! Und die Archive lassen sich NICHT entpacken, wenn das Hauptprogramm nicht mehr vorhanden ist und dazu noch im selben Ordner liegt... sollten das nicht selbstentpackende Archive sein??

[Feltzkrone]

Bei mir isses nicht viel langsamer als WinRAR 3 mit maximaler Kompression. Wie gesagt, libbzip2 bietet einen recht starken Kompressionsalgorithmus der jeweils 900 KB zu einem Block zusammen fasst und anschliessend komprimiert. Daher die eine Sekunde Pause die immer zwischendurch zustandekommt. Dagegen kann man leider nichts machen.

Von SFX hab ich nie gesprochen. Wenn ich bedenke, dass es auch mit den neusten RAR-Archiven haufenweise Probleme gab, weil sie mit Versionen kleiner 3.0 nicht zu entpacken waren, dann sehe ich das nicht als Grund, unbedingt SFXe zu erstellen. Ich denke mal, dass RCAM zumindest hier irgendwann bekannt genug ist, dass jeder mit dem Dateiformat das Programm in Verbindung bringen kann.

Dass die Systemauslastung bei 99% liegt ist doch nix schlimmes! Wenn Windoof gerade nichts anderes zu tun hat waere es schliesslich FATAL, dem Programm, das gerade im Vordergrund laeuft, nicht die volle CPU-Power zuzusprechen.

Was meinst Du mit "und dazu noch im selben Ordner liegt"?

Edit: SFX-RCAs wuerden durch libbzip2 schon 50 KB schwerer, und durch den Delphi-Teil mit Sicherheit nochmal so um die 250 KB. Wenn jedoch jemand einen brauchbaren SFX-Teil in einer nicht so aufgeblasenen Sprache schreiben wuerde, wuerde ich so eine Funktion einbauen.

[Feltzkrone]

Also, bitte abstimmen! Mir ist uebrigens noch ein Nutzen des Programms aufgefallen.

Wenn jemand ein Release als RCA macht, sollte er auch ein RCI davon in den Share stellen, wobei alle Dateien (Playlists, NFOs usw.) ausser die MP3s an sich uebernommen werden. Wenn es naemlich nicht selbstgerippt ist (nur dann ist es sinnvoll), ist die Wahrscheinlichkeit gross, dass jemand anders die gleichen Mp3s auch schon hat. Dieser jemand koennte dann die gleiche RCA-Datei mithilfe der RCI erstellen und auch in den Share packen. Man haette dann gleich ein paar Quellen mehr.

[Darkness666]

Von SFX hab ich nie gesprochen. Wenn ich bedenke, dass es auch mit den neusten RAR-Archiven haufenweise Probleme gab, weil sie mit Versionen kleiner 3.0 nicht zu entpacken waren, dann sehe ich das nicht als Grund, unbedingt SFXe zu erstellen.

Das stimmt allerdings. beim entpacken von "RAR" hab ich auch schon oefters probs gehabt, OBWOHL ich 3.0 draufhab. "fehler in Datei" oder "fehler in archiv" oder so hiess der fehler. entweder das prog hat schon bugs beim packen, oder es is nich mit allen versionen abwaertskompatibel, wuerd ich sagen