Moin !

Hat von euch schon mal jemand mit einer Single File Storage Komponenten gearbeitet?
Also sowas hier:
http://gp.17slon.com/gp/gpstructuredstorage.htm
http://www.accuracer.com/single-file...ile_system.htm

Kann man damit in einem virtuellen "Verzeichnis" direkt speichern? Oder muss man erst die Dateien auf der Platte erstellen und dann dem Storage Teil sagen welche Dateien es beinhalten soll?

Liegen die Daten dann eigentlich im Speicher, oder arbeiten diese Teile direkt auf Festplatte?

Vielleicht kann ja jemand mal kurz ein paar Erfahrungen posten. Da wir aus unserer Anwendung viele Verschiedene Dateien speichern können wäre es eine feine Sache, wenn man die gleich in so einem Single File bündeln könnte.
Das würde uns einiges an Datei und ZIP Code ersparen.

Einges arbeitet direkt in der Datei, Anderes arbeitet mit einer Kopie im RAM und speichert erst wenn fertig.
Bei Einigen kann man keine Dateien ändern/löschen, ohne das komplette Archiv neu abzuspeichern.
Bei Manchen kann man Dateien über einen Puffer/Pointer/Stream hinzufügen und bei Anderen kann man nur über eine Datei auf der Platte gehn.

Es gibt eigentlich alles und demnach kann man nichts Genaues und Allgemeines drüber sagen.

Selbt bei Zip gibt es einige Libs, welche die ZIP im RAM und somit schneller verwalten können, bei Änderungen.

Interessant wäre auch VHD oder VMDK, zumindest ersteres liese sich ab Win7 einfach mounten und wir ein normales Laufwerk "füllen".

Diese VHD und Co. gehören zum VPC.
Und sie sind nicht direkt für eine Dateispeicherung geeignet.
Sie stellen nur eine virtuelle Festplatte dar, worin erstmal ein Dateisystem "installiert" werden muß.
Dieses Dateisystem wird dann über einen passenden und im System registrierten Dateisystemtreiber verwaltet.

Eine Frage wäre auch noch, ob Win7 diese VHDs ebenfalls noch mounten kann, selbst wenn kein VPC, bzw. keine XP-VM installiert sind.



Im Grunde kommt es erstmal darauf an, was alles gemacht werden soll
und wie schnell/optimal dieses ablaufen soll.
Dann könnte man mal schauen was zur Auswahl steht und welches davon dann am optimalstens paßt.

VHD oder VMDK sind erstmal nur SingleFile-Storages, die von bekannten VMs als Festplatte genutzt werden. Wenn es wie eine festplatte angesprochen wird, umso besser, geht ja um Dateien, nicht um Daten.

Windows 7 prof. kann VHDs mounten (sogar als Bootlaufwerk), da das als Erleichterung auf Entwicklerseite vorgeschlagen war, sollte das reichen.

Auf Anwenderseite wird natürlich nicht über das Betriebssystem auf die VHD etc. zugegriffen. Unter C# gibt es die DiscUtils, mit denen kann man direkt darauf zugreifen (FileStream etc.) Denke solche Komponenten gibt es für die bekannten Formate auch in Delphi.

VHD (Microsoft) und VMDK (VMWare) sind keine FileStorages.
Sie können im Großen und Ganzen nur "Cluster" verwalten, mehr auch nicht.

Datei > unterschiedliche Größen > Zugriff meißt über Dateiname oder Index mit zusätzlichem (Datei)Namen
Cluster > einheitliche Größe > Zugriff über Index

Um einen Dateispeicher (FileStorage) in Cluster aufzuteilen, wird eben noch ein Dateisystem (FileSystemDriver) benötigt.


Nja, die VHDs-Specs sind recht übersichtlich, also könnte man sich da notfalls selbst was übersetzen, aber wenn man sich keine eigene Dateisystemkomponente aufsetzen will (wobei ja die FATs auch recht "einfach" sind), wird man mit einem direkten Zugriff auf diese Dateien nicht weit kommen.

Zitat von himitsu:

keine FileStorages.

Ist ein SingleFile-Storage... der Bindestrich ist da schon wichtig

Es ging ja darum mehrere Dateien in einer einzelnen Datei zu speichern, ohne zu spezifizieren, wie das interne Speichersystem aufgebaut sein muss. Ist doch völlig egal, ob das ein Clustersystem oder Binärstream ist. Wichtig ist nur, das es eine Möglichkeit gibt, aus der Anwendung heraus die Dateien aus dem Storage zu lesen und zu verwenden. Gibt ja VHD-Viewer, die unabhängig von der Umgebung Inhalt anzeigen und extrahieren können.

War ja auch nur ein Vorschlag...

markieren

Code:

long diskSize = 30 * 1024 * 1024; //30MB
using (Stream vhdStream = File.Create(@"C:\TEMP\mydisk.vhd"))
{
  Disk disk = Disk.InitializeDynamic(vhdStream, diskSize);
  BiosPartitionTable.Initialize(disk, WellKnownPartitionType.WindowsFat);
  using (FatFileSystem fs = FatFileSystem.FormatPartition(disk, 0, null))
  {
    fs.CreateDirectory(@"TestDir\CHILD");
    // do other things with the file system...
  }
}

Sein erster Link (Zitat aus den Spezifikationen):

Zitat:

GpStructuredStorage compound file is organized in 1 KB blocks. First block contains header, then the content alternates between a file allocation table (FAT) fragment block and 256 blocks managed by the preceeding FAT fragment. Each block can be represented by a number - header block is block #0, first fat fragment is block #1 and so on.

Ich geh' jetzt ins Bett...

BiosPartitionTable & FatFileSystem ... wie gesagt, VHD selber kann es nicht.

Klar, wenn man eine Lib findet (in Delphi wird's schon schwerer), dann kann man schon mehr damit machen.
Auf 'ner unpartitionierten und unformatierten Festplatte kannst'e ja och nicht so einfach Dateien ablegen.

Aber ob sich dann der Aufwand lohnt?
Da könnte man auch bei Zip oder 7-Zip bleiben.

Moin !

Ich glaube wir driften hier etwas vom Thema ab, oder?

Zitat:

VHD oder VMDK

Ich denke mal das fällt beides raus. Oder kann mir jemand zu den beiden Typen eine bazahlbare Delphi Lib nennen

Zitat:

Einges arbeitet direkt in der Datei, Anderes arbeitet mit einer Kopie im RAM und speichert erst wenn fertig.
Bei Einigen kann man keine Dateien ändern/löschen, ohne das komplette Archiv neu abzuspeichern.
Bei Manchen kann man Dateien über einen Puffer/Pointer/Stream hinzufügen und bei Anderen kann man nur über eine Datei auf der Platte gehn.

Also was bei uns nur sinnvoll wäre:
* arbeitet direkt in einer Datei und nicht im RAM
* löschen & ändern von Dateien muss vorhanden sein ohne das File neu zu schreiben
* hinzufügen direkt - ohne den Umweg über eine extra Datei im Dateisystem

Sollte es dieses Konstrukt so gar nicht geben, dann könnten wir die Sache auch mit ZIP umsetzen.

Hast du dir schonmal die 7Zip-API angesehn?
Da gab's doch auch was für Delphi.

Nja, wenn man etwas nutzt, welches die Dateien zusammenhängend und ohne Lücken speichert, wie z.B. beim ZIP, dann müssen alle Daten dahinter verschoben werden, wenn man eine enthaltene Datei ändert, löscht oder mitten drin einfügt.
Beim ZIP ist z.B. das "Verzeichnis" am Dateiende und da sich viele Libs die Arbeit mit dem Verschieben und Umrechnen der neuen Positionen sparen, machen sie es meißt über eine Tempdatei, wo die ganze ZIP neu aufgebaut wird.

Für mein himXML gibt es auf der ToDo-Liste einen Punkt, wo es um eine InFile-editierbare binär-Version der XML-Daten geht, welches auch noch in mit einer Kompression versehn werden kann, dieses könnte man dann vermutlich recht gut für soeine FileStorages, mit Zusatzinfos, verwenden.
Das Konzept steht eigentlich schon seit einer ganzen Weile, aber andere Dinge hatten bisher einfach Vorrang.