libsqlfs
sqlfs
libsqlfs | sqlfs | |
---|---|---|
10 | 1 | |
617 | 19 | |
0.0% | - | |
0.0 | 10.0 | |
over 1 year ago | over 4 years ago | |
C | Python | |
GNU Lesser General Public License v3.0 only | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
libsqlfs
-
The File Filesystem
Closest I found: https://github.com/guardianproject/libsqlfs
> The libsqlfs library implements a POSIX style file system on top of an SQLite database. It allows applications to have access to a full read/write file system in a single file, complete with its own file hierarchy and name space. This is useful for applications which needs structured storage, such as embedding documents within documents, or management of configuration data or preferences. Libsqlfs can be used as an shared library, or it can be built as a FUSE (Linux File System in User Space) module to allow a libsqlfs database to be accessed via OS level file system interfaces by normal applications.
-
Why you should probably be using SQLite
- Use clone file to duplicate the cached data directory to give to individual tests.
One thing I'd like to pursue is to store the Postgres data dir in SQLite [1]. Then, I can reset the "file system" using SQL after each test instead of copying the entire datadir.
[1]: https://github.com/guardianproject/libsqlfs
-
SQLite: 35% Faster Than the Filesystem
Not sure about compression but somebody could probably hack it in an afternoon using this:
https://github.com/guardianproject/libsqlfs
or something similar to check the potential for speed up.
- Libsqlfs: A Posix-style file system on top of an SQLite database
- FUSE based Posix style file system on top of an SQLite database
-
Why the Windows Registry sucks technically (2010)
Maybe there isn't a database engine that explicitly supports file system daya structures, but you could implement a filesystem in the application layer using SQLite as a storage mechanism.
Here's an example of someone doing that very thing.
https://github.com/guardianproject/libsqlfs
- Is it time to remove reiserfs?
- SQLite Archive Files
-
A Future for SQL on the Web
now let's see what it takes to make absurd-fs, where we use https://github.com/guardianproject/libsqlfs to make a filesystem on top of sqlite on top of the File System Access API.
gotta keep ourselves fully looped. ⥀
sqlfs
-
Why the Windows Registry sucks technically (2010)
For those looking for a more up to date alternative, with a non-hardcoded DB file path, try https://github.com/greenbender/sqlfs (not affiliated, just had a look in this area a few weeks ago)
What are some alternatives?
sqlitefs - sqlite as a filesystem
dirs-rs - moved to https://codeberg.org/dirs/dirs-rs
StorX - PHP library for flat-file data storage
nix-book - Nix documentation – centralized community online learning resource for Nix
sqlite-zstd - Transparent dictionary-based row-level compression for SQLite
camellia - A lightweight, persistent, hierarchical key-value store, written in Go