Virtuelles Dateisystem

[Codewalker]

Ich bin auf der Suche nach einer Möglichkeit (Klassen), mehrere Dateien in einer Datei zu speichern und auf einzelne Dateien zur Laufzeit zugreifen zu können. Zusätzlich sollte man noch die Dateien mit Pfaden ablegen können, um eine Art Baumstruktur zu machen. Ganz wichtig ist mir, dass ich zum laden einer Datei des Archivs nicht das ganze Archiv im Speicher hängen habe, sondern wirklich nur den Teil laden, den ich brauche.

Bei Torry habe ich dazu das SingleFileDataStorage gefunden, aber das erzeugt immer wieder ominöse Fehler beim Einlesen vorhandener Dateien (es lässt die Borland Debugger-DLL abschmieren). Kennt jemand brauchbare Alternativen oder Lösungen dazu?

[MrKnogge]

Du könntest es "entpackt" in den temporären Ordner speichern.

[peschai]

Hallo,

Wie wäre es mit ZIP-Komponenenten ?

[Bernhard Geyer]

Solid File System

[mkinzler]

Weitere:
-sfs
-Virtual Stream

[quantum]

GpStructuredStorage
http://gp.17slon.com/gp/

[Codewalker]

Danke für die vielen Antworten. GpStructuredStorage gefällt mir bis jetzt am besten (nicht zuletzt durch das Total Commander Plugin). Klappt auch alles, nur schaffe ich es nicht, Dateien in das Archiv zu packen. Weiß jemand Rat? (Weil sonst macht das ganze wenig Sinn und man sollte in diesem Zusammenhang davon abraten)

[mimi]

Es kommt auf dein Verwendung zweck an. Was hast du damit vor ? Wie groß soll die Datei werden ?

Soll nur lesend drauf zugegrieffen werden ist das relativ leicht mit TFileStream. Aber beim Schreiben wird es schwer.
ist die Dateigröße wichtig ?

Ich versuche gerade selbst so ein Format zu schreiben:
Es gibt Blöcke mit Fester Größe. Jeder Angelegte Tabelle besteht aus z.b. 20 Einträgen die sind von der Länge her fest. Die Länge der Einzelnen Datenstätze kannst du beim erstellen mit angeben. Daraus berechne ich die Zeilen Länge. Im Prinzip währen auch Dynamische Datentypen möglich aber das währe alles aufwendiger.

Meine Idee hätte den Vorteil das die Datei nicht komplett eingelesen werden müsste sondern nur das was du brauchst. Schreiben geht ganz einfach wenn es sich um einfache Datentypen wie Strings oder Integers handelt.

bei Dateien ist das schon schwirger aber nicht unmöglich.

Im Moment hänge ich noch bei den Grundlagen fest. Das ändern von Tabellen Einträge.
Ein Baum Format währe damit auch denkbar. Jede Tabelle zeigt einfach auf eine Andere Tabelle. Damit könnten die Daten so abgerufen werden wie im Dateisystem. Es soll einige Standard Variablen geben die von der Klasse selber gesetzt und geändert werden wie z.b. wie oft wurde dieser Eintrag abgerufen ? Wann wurde er erstellt ? und solche fragen.

[Codewalker]

Nach einigen Startschwierigkeiten komme ich jetzt ganz gut klar und kann mal folgendes über GpStructuredStorage sagen: Anfangs war ich etwas irritiert, weil es alle auf Interfaces aufbaut. Im Nachhinein macht alles Sinn und ist super einfach zu benutzen. Es verhält sich letztlich wie eine Art Datenträger. Der Zugriff läuft vollständig über Streams, so dass man bestehende Lade-/Speicherroutinen nicht anpassen muss. Die Daten können in einer Baumstruktur abgelegt werden und sind in der Größe nur auf 2 GB beschränkt (reicht mir :mrgreen: ).

Es fehlt nur an drei Dingen:

• Eine gute Dokumentation, man muss (wie bei so vielem) sich einiges Zusammensuchen. Liegt auch z.T. am schlechten Demo
• Einen guten Editor, um schnell Dateien zusammenzubauen (musste ich mir selber schreiben)
• Eine Funktion, um alle enthaltenen Verzeichnisse in einem Baum darstellen zu können. (Musste ich mir auch über eine rekursive Funktion mit ein paar Tricks zusammenbauen)

Unterm Strich kann ich nur sagen: Empfehlenswert. Ist genau das, was ich gesucht habe und wird auch häufig eingesetzt (z.B. von den GExperts für die CodeLib)

@Mimi: Quelltext ist mit dabei, vielleicht kannst du dir da ja ein wenig Inspiration holen. Scheint da zumindest alles gut gelöst zu sein

[Ghostwalker]

@Codewalker

Wie wärs mit einem kleinen Tutorial ? :) Ich denke das das Thema viele interessieren würde :)

[mimi]

@Codewalker
Danke, ich werde es mir gleich mal anschauen bzw. danach suchen.
Wird die Datei denn bei jeder Änderung komplett neu erstellt ?

Evlt. gibt es sowas ja auch für Lazarus.

[Codewalker]

Ich übersetze gerade schon die Andorra Tutorials - aber später lasse ich mit mir reden.
Aber für alle Interessierten hänge ich mal das Beispiel an. Es besteht aus den 3 GP-Quelldateien und meinem kleinen Demo. Ist bei weitem nicht perfekt, daher kurze Anleitung:

1. Als allerersten im Menü den Eintrag für ein neues Archiv wählen (oder ein vorhandenes Öffnen).
2. Danach ist freies Arbeiten möglich. Das Extrahieren von Dateien ist aber derzeit noch nicht möglich.

Im Quellcode (ist jetzt aber nicht sonderlich aufgeräumt und schön) solltet ihr alles finden, was man braucht. Wer noch weitere Ideen oder Verbesserungen vornimmt, kann sie ja gerne hier posten. Vielleicht kriegen wir das ja zu einem verwendbaren Päckchen zusammen.
Wer seine Dateien wieder braucht kann auch ein Plugin für den Total Commander installieren. Das kann aber nur extrahieren und nicht reinpacken (also eher eine Notlösung). Link muss ich wieder raussuchen, kann ich gerade nicht mit dienen.

Ich will das ganze mit Andorra nutzen, werde also noch das ein oder andere daran basteln und auch eine Hilfsunit für Andorra schreiben. Aber gut Ding will Weile haben...

@mimi: Das mit dem neu erstellt habe ich mir noch nicht angesehen, wird aber rauszukriegen sein.

[Codewalker]

Zu der Frage, ob immer alles eingeleen wird: Ich habe ein wenig getestet.
Die Funktion ReadFile liefert einen Stream zurück, der genau den Teil des Archivs liest, der die gewünschte Datei enthält. Es wird also nicht immer alles eingelesen.
Das ganze macht es sehr bedienbar und speicherschonend, hat aber zwei kleine Nachteile:

1. Man kann das Archiv nicht komprimieren (dann müsste der Stream angepasst werden und entsprechend weniger lesen - ist also aufwändig)
2. Man kann Dateien nicht nachträglich vergrößern. Wenn an Dateien etwas angehangen werden soll, dann muss die bestehende Datei im Archiv entfernt werden und durch die neue, größere Datei ersetzt werden. Dadurch entsteht in der Datei ein "Loch" ähnlich wie man es von Datenbanken kennt (die ja, vereinfacht gesagt, nicht anders arbeiten). Durch den Aufruf der Methode Compact wird das gesamte Archiv neu geschrieben und die Löcher sind weg. Das erfordert je nach Größe des Archivs aber ein klein wenig Zeit.

Insgesamt sind das, imho geringfügige Einschränkungen die mich nicht stören. Wenn man die Streams geschickt einsetzt, kann man Dateien in einen Editor laden und die geänderten danach wieder zurückschreiben. Man muss dann nur regelmäßig Compact aufrufen (am besten beim Beenden).

Wer nutzt das denn noch oder will es nutzen und wofür? Würde mich mal interessieren...

[mimi]

Klinkt nicht schlecht. Hört sich nach meiner Idee an die ich gehabt habe. Das mit dem Löschen ist klar.

Das Mit den Dateien einfügen das ist noch doof das da die Größe nicht geändert werden kann(oder sehe ich das falsch ?)

Ich würde sowas bei meinem Spielen einsetzten. z.b. für ein einfachers Level Format.

Im Moment ist das einfach nur Ascci und kann enweder in einem einfachen Archive gespeichert werden oder als einzelnen Dateien. Aber die Umsetzung gefällt mir nicht.

und ich könnte so ein Virtualles Dateisystem für mein "Notezien Verwalter" verwenden. Dort nutze ich im Moment die Speicher und Lade Funktion von der VST Komponente.

Ach ja: Die Datei wird nicht neu erstellt beim verändern oder ?

Währe toll wenn das auch unter Lazarus läuft.

[Codewalker]

Nein, die Datei wird nicht neu erstellt. Er hängt es einfach hinten dran und lässt in der Mitte (wo die alte Datei war) eine Lücke. Das Archiv belegt dann mehr Platz als die darin enthaltenen Dateien. Dann muss man Compact aufrufen und er schreibt das ganz ohne Lücken neu.

Die Größe einer einmal enthaltenen Datei kannst du nicht ändern. Dazu muss sie neu eingefügt werden (s.o.)
Und was Lazarus angeht: Ich nehme mal an, dass Lazarus Interfaces versteht - dann habe ich auf einen schnellen Blick nichts gesehen, was dagegegen sprechen sollte

[mimi]

Gut Danke ! Werde ich gleich mal ausprobieren.... das mit der Lücke ist doof, ich hatte Gehofft das sie wieder gefüllt wird automatisch mit neuen Daten.

[Codewalker]

Naja, dann müsste man ja eine Datei haben, die exakt auf das Byte genau in die Lücke passt. Das wird wohl nicht gehen. Aber durch den einmaligen Aufruf von Compact verschwinden ja alle Lücken - ist also leicht zu umgehen

[mimi]

nach meiner Idee schon, ist es aber nicht so einfach:
Ich packe eine Datei in das Archiv lösche sie und packe eine neue wieder rein.
jetzt wird der Platzt der Alten Datei übernommen und der Rest am ende eingefügt.
Das lesen wird natürlich aufwendiger das ist klar und es ensteht ein durcheinander in der Datei aber es geht.

ich habe sie mir gerade gedownlodet. Ich werde sie mir mal anschauen.

[freak4fun]

Ich würde gern wissen wofür man das braucht. :)

[mimi]

Ist doch ganz einfach, wenn man Daten in einem Spiel speichern möchte und nicht 1000 einzelne Dateien haben möchte. Im Prinzip könnte man auch einfach ZIP nehmen, aber so ist das "schöner" finde ich.

[Codewalker]

Außerdem ist es sehr viel Arbeit, Animationen und Grafiken mit Alphakanal spielgerecht aufzubereiten. Die will man auch ungerne als einzelne Dateien dazupacken. Ein klein wenig Verschachtelung in nicht ganz gängige aber zweckmäße Archive ist ganz nett. Allerdings will man ja dafür nicht alle Lade-/Speicherroutinen neu schreiben müssen. Daher also das virtuelle Dateisystem - da läuft alles über Streams und man kann die altbekannten LoadFromStream etc. nutzen

[mimi]

hast du mal ein Beispiel wie das Funktioniert mit dieser Klasse ?

[Olli]

Sucht doch mal nach Win32-Funktionen die mit "Stg" anfangen. Nennt sich Structured Storage und kommt schon mit dem System (OLE-Bestandteil).

[mimi]

naja ich dachte in allgemeines wie das ding Funktioniert ich habe hier keine Win32 Funktionen zu Verfügung unter Linux...

[Codewalker]

@Mimi: Im Prinzip ganz einfach. Gehen wir mal davon aus, du hättest eine DAtei mit folgender Dateistruktur

Code:

\
     \Ordner1
           \Test.txt
           \Bild.bmp
     \Ordner2
          \SubOrdner1
               \Test.txt

Wenn du jetzt die Dateien lesen willst, geht das als Beispiel wie folgt:

Delphi-Quellcode:

var
     Storage: IGpStructuredStorage;
begin
 Storage := CreateStructuredStorage; // Interface instanziieren, daher auch kein Free am Ende
 Storage.Initialize('Test.dat',fmOpenRead); // Die eigentliche Datei öffnen (mit fmCreate wird einen neue erzeugt)
 Memo1.Lines.LoadFromStream(Storage.OpenFile('\Ordner1\Test.txt', fmOpenRead);
 Memo2.Lines.LoadFromStream(Storage.OpenFile('\Ordner2\SubOrnder1\Test.txt', fmOpenRead);
 Image1.Picture.LoadFromStream(Storage.OpenFile('\Ordner1\Bild.bmp',fmOpenRead);
end;

Das ist jetzt aber die absolute Quick & Dirty Methode. Die Funktion OpenFile gibt einen Stream zurück, den ich hier natürlich nicht wieder freigebe. Aber ich wollte es mal so kurz wie möglich halten. Ansonsten verlängert sich der Aufruf um 2 Zeilen (erst Stream holen, dann LoadFromStream aufrufen, dann Stream wieder freigeben).

Ich finde das ganze angenehm einfach und flexibel

@Olli: Stimmt, bin ich auch schon drüber gestolpert. Leider aber auf COM aufbauend und so keinesfalls portierbar (korrigier mich, wenn ich mich irre)

[mimi]

das sieht gut aus, werde ich bei Gelegenheit mal ausprobieren

[Codewalker]

GPStructuredStorage wurde überarbeitet und ist jetzt auch kompatibel mit Delphi 2009 (http://17slon.com/gp/gp/gpstructuredstorage.htm). Alte Archive werden automatisch "geupdated" beim Öffnen. Neue Archive können von alter Version nicht geladen werden.

Die alte Version kompiliert zwar ohne Meckern in Delphi 2009, die entstehenden Archive sind aber nicht verwendbar und nach einmaligem Schreiben ist meist nur noch Datenmüll übrig.

[jbaertle]

Kannst Du noch einen Kommentar zur Lese- und Schreib-Performance insbes. bei vielen kleineren Dateien abgeben?
MfG Jani.

[Codewalker]

Zitat:

Zitat von jbaertle

Kannst Du noch einen Kommentar zur Lese- und Schreib-Performance insbes. bei vielen kleineren Dateien abgeben?
MfG Jani.

Die Komponente ist nicht von mir, daher ... ähm... nein, kann ich nicht :mrgreen: .
Ich nutze Sie aber zum Laden von Texturepaketen in meinem Spiel und kann über die Performance nicht meckern. Ist kaum merklich bisher

[shadowman]

Hallo,

lange her, als hier das letzte Mal gepostet wurde, aber dieser Thread passt zu meinem Anliegen:

wir haben SingleFileDataStorage 1.4.1 im Einsatz, doch dummerweise scheint die Komponente probleme mit Nicht-ANSI-Zeichen zu haben, obwohl bei Torry in der Beschreibung steht, dass Unicode-Dateinamen möglich sind.

Intern in den Sourcen wird mit AnsiString gearbeitet und sobald im Dateinamen z.B. ein "Ş" vorkommt, tritt beim Schreiben dieser Datei ins Archiv ein Fehler auf, dass die Datei XYZ nicht geöffnet werden kann. Im in der Meldung angezeigten Dateinamen sieht man dann ein normales "S" und so heißt die Datei ja nicht.

Die Komponente wird wohl nicht mehr weiterentwickelt, der Author nicht erreichbar...

Da die letzten Posts hier vier Jahre zurückliegen, wollte ich nachfragen, wie es inzwischen aussieht, ob es die weiter oben gennanten Alternativen noch gibt (AidAim und Eldos gibt es wohl), ob es neue gibt und welche der Alternativen der SingleFileDataStorage-Komponente am nächsten kommt (falls man die überhaupt vergleichen kann), damit möglichst wenig geändert werden muss...

Würde mich über Hinweise sehr freuen!