Open-Source-Bibliothek für eingebettete Dateisysteme (oder virtuelle Einzeldatei-Dateisysteme oder strukturierte Speicherung) für C [closed]

Lesezeit: 5 Minuten

Benutzer-Avatar
Ian

Ich bin mir nicht sicher, was der “allgemeine” Name von so etwas sein könnte. Ich suche nach einer Bibliothek, die mir ein Dateiformat gibt, um verschiedene Arten von Binärdaten in einer expandierenden einzelnen Datei zu speichern.

  • Open Source, nicht GPL (LGPL ok)
  • C-Schnittstelle
  • das Dateiformat ist eine einzelne Datei
  • mehrere Dateien innerhalb einer POSIX-ähnlichen Datei-API (oder mehrere “Blobs” innerhalb einer anderen API)
  • Datei-/Strukturbearbeitung erfolgt direkt vor Ort
  • erstens zuverlässig, zweitens leistungsfähig

Beispiele beinhalten:

Probleme mit den oben genannten:

  • whefs scheint nicht sehr ausgereift zu sein, beschreibt aber am besten, wonach ich suche
  • HDF, CDF, NetCDF sind verwendbar (auch sehr zuverlässig und schnell), aber sie sind ziemlich kompliziert und ich bin nicht ganz von ihrer Unterstützung für undurchsichtige binäre “Blobs” überzeugt.

Bearbeiten:

Vergessen zu erwähnen, eine andere relevante Frage:
Einfaches virtuelles Dateisystem in C/C++
Noch eine ähnliche Frage:
Gibt es eine Open-Source-Alternative zu zusammengesetzten Windows-Dateien?

Bearbeiten:

Bedingung für In-Place-Bearbeitung hinzugefügt.

Bearbeiten:

whefs ersetzt durch: whio_epfs

  • WURZEL (root.cern.ch) implementiert so etwas in seinem TFile-Format, aber das ist C++.

    – dmckee — Ex-Moderator-Kätzchen

    25. Februar 2010 um 21:08 Uhr

Dies scheint zu tun, wonach ich gesucht habe: libgsf

Muss noch seine Zuverlässigkeit/Leistung testen und wie plattformübergreifend das Binärformat ist.

  • Ist es nicht nur für Archive wie gzip? Welche Art von virtuellem Dateisystem unterstützt libgsf?

    – Chris Pillen

    6. Februar 2014 um 18:53 Uhr

  • Es unterstützt GZip, aber der Anwendungsfall hier war eher die Unterstützung dieses Formats: msdn.microsoft.com/en-us/library/dd942138.aspx

    – Ian

    6. Februar 2014 um 21:27 Uhr

  • Verstanden. Eine letzte Frage: Was hältst du von POLE? Und erstellt libgsf endlich auch solche OLE-Container mit fester Größe?

    – Chris Pillen

    8. Februar 2014 um 12:54 Uhr

  • Ich bin mit diesem Format nicht vertraut und habe es in den libgsf-Dokumenten nicht erwähnt.

    – Ian

    10. Februar 2014 um 13:23 Uhr

  • SQLite (sqlite.org) wird die Arbeit auf robuste Weise erledigen, mit zusätzlicher relationaler Soße, falls Sie dies benötigen.

    – MikeW

    5. Juni 2017 um 10:06 Uhr


Es hört sich so an, als würden Sie über das Linux-Loopback-Gerät sprechen, mit dem Sie eine Datei in einem Dateisystem als erstklassiges Blockgerät behandeln können (und dann mit mkfs, mount usw. fortfahren).

(Auf welche Art von Plattform zielen Sie ab? Eine voll funktionsfähige Unix-ähnliche? Etwas im Embedded-Bereich mit geringem Platzbedarf?)

  • Cross-Plattform ist die Absicht. Sicherlich Windows und eine eingebettete Linux-Version. Ich habe das Loopback-Gerät in Betracht gezogen, aber nicht erwähnt, weil ich nicht sicher war, ob es größer werden kann und unter Windows nicht funktioniert.

    – Ian

    25. Februar 2010 um 20:08 Uhr

  • Recht. Wenn ich an Ihrer Stelle wäre, würde ich mir auch die verschiedenen Dateisysteme mit Protokollstruktur ansehen, um zu sehen, ob es eines mit einer akzeptablen Lizenz gibt, das Sie gut genug hacken könnten, um im Userland zu arbeiten und eine Datei als abzuarbeiten Sicherungsspeicher (im Gegensatz zu einem Blockgerät).

    – Verrückter Schotte

    25. Februar 2010 um 22:11 Uhr

Die WxWindows-Bibliothek unterstützt ZIP-Dateien (siehe http://docs.wxwidgets.org/stable/wx_wxarc.html#wxarc). Das hat auch den Vorteil, dass man sich die Inhalte mit einem ZIP-Manager (zB WINZIP) anschauen kann.

Eine kommerzielle Alternative ist ChillKat (http://www.chilkatsoft.com/)

Wenn die Sicherheit ein Problem darstellt, verschlüsseln Sie den Dateiinhalt und ändern Sie die Dateinamen im ZIP-Archiv.

  • Sicherheit ist kein Problem. Ich habe mich nicht allzu sehr mit normalen Archivtypen befasst, aber ich frage mich, wie gut sie in Bezug auf große Datensätze, hohe Geschwindigkeit, wahlfreien Zugriff auf den internen Dateiinhalt und gleichzeitiges Lesen / Schreiben abschneiden …

    – Ian

    25. Februar 2010 um 21:03 Uhr


Eet-Bibliothek aus dem Enlightenment-Projekt vielleicht?

http://en.wikipedia.org/wiki/Enlightenment_Foundation_Libraries#EET
http://docs.enlightenment.org/api/eet/html/

Wie wäre es mit BerkeleyDB? Es ist nicht gerade ein Dateisystem, aber es ist ziemlich transparent, “Binärdaten” in einer Datei zu speichern. Die Lizenz scheint auch recht freizügig zu sein.

  • Entsprechend oracle.com/technology/software/products/berkeley-db/htdocs/… es erfordert eine kommerzielle Lizenz für Closed-Source-Anwendungen. Außerdem weiß ich nicht, wie viel schneller es ist als SQLite, das ein paar Mal langsamer war als das direkte Speichern in einer Datei. Dies war ein einfacher Test, Batch-Commit zum Speichern von Daten.

    – Ian

    22. März 2010 um 12:24 Uhr

  • Nun, Sie haben nicht erwähnt, dass Sie eine Closed-Source-Anwendung machen. Und ja, es könnte genauso wie SQLite sein, aber mit ein paar Jahren mehr Stabilität auf der eingebetteten Seite.

    – Lorenzog

    22. März 2010 um 15:33 Uhr

  • Entschuldigung, mein Kommentar war irreführend. Die aktuelle Open-Source-Lizenz von BerkeleyDB ist GPL-ähnlich (d. h., sie erfordert die Veröffentlichung Ihrer gesamten Anwendungsquelle) und verstößt gegen eine der Anforderungen, die ich in der Frage erwähnt habe.

    – Ian

    29. März 2010 um 18:23 Uhr


  • Entsprechend oracle.com/technology/software/products/berkeley-db/htdocs/… es erfordert eine kommerzielle Lizenz für Closed-Source-Anwendungen. Außerdem weiß ich nicht, wie viel schneller es ist als SQLite, das ein paar Mal langsamer war als das direkte Speichern in einer Datei. Dies war ein einfacher Test, Batch-Commit zum Speichern von Daten.

    – Ian

    22. März 2010 um 12:24 Uhr

  • Nun, Sie haben nicht erwähnt, dass Sie eine Closed-Source-Anwendung machen. Und ja, es könnte genauso wie SQLite sein, aber mit ein paar Jahren mehr Stabilität auf der eingebetteten Seite.

    – Lorenzog

    22. März 2010 um 15:33 Uhr

  • Entschuldigung, mein Kommentar war irreführend. Die aktuelle Open-Source-Lizenz von BerkeleyDB ist GPL-ähnlich (d. h., sie erfordert die Veröffentlichung Ihrer gesamten Anwendungsquelle) und verstößt gegen eine der Anforderungen, die ich in der Frage erwähnt habe.

    – Ian

    29. März 2010 um 18:23 Uhr


1228730cookie-checkOpen-Source-Bibliothek für eingebettete Dateisysteme (oder virtuelle Einzeldatei-Dateisysteme oder strukturierte Speicherung) für C [closed]

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy