Suzuki Ichiro wrote:
On 2018/05/16, Paul wrote:

You could use Linux, to convert the tiny file in the
"database" folder, into separate files, to better understand
what exactly is in there.

Even using a hex editor, like HxD, you can get some idea
what entries are in there.

Interesting idea to look inside the edb file:
%HOMEPATH%\AppData\Local\TileDataLayer\Database\ve datamodel.edb
http://i.cubeupload.com/YRxNRK.jpg

Do you think the "edb" is the critical file?
It's only 1MB (literally 1024KB, while the rest are literally double that).

The file sizes in that directory seem pre-ordained.
http://i.cubeupload.com/LSBPGI.jpg

In databases, generally a power-of-two quanta is used
to bump up the size of the main database file. Some databases
use 64KB quanta, others 256KB.

For example, a database with nothing in it, might be
256KB in size. If you write 256KB+1byte of content to
the database, on the last byte, the allocator bumps the
..edb file size to 512KB. So space is "reserved" in a sense,
before it is needed. The newly allocated chunk holds zeros,
until a write process decides to load non-zero content
into it.

That will help account for the "nice round numbers" you
see for .edb file size.

Then, what do I check for ? The .edb can never be zero bytes
in size - if it were, it would mean no software is running
to manage the file. If the file is "min_size", it could
be empty, having from 0 to 256KB of content. If the file
is 1024KB, then we know the real content size is between
768KB and 1024KB.

That's a hint that *something* is stored in there. And if you
only needed 1KB of information per entry, then you could
store a thousand entries in that much space.

Using a database dumper, would attempt to use the schema
information inside the database file, to dump the contents
in a semi-intelligent fashion. The database dumping process
doesn't tell you the relationship between internal chunks.
For example, to piece together the names of all the files
scanned by Windows Search, requires reading two dumped files
in tandem to make sense of what's inside the database.
The database is relational, and when you tear a database
apart with a dumper, the relations could be lost, and you
have to use your noodle to figure it out then.

In Firefox, multiple sqlite files are tied to one
another by index numbers. The "schema" used to be available
as a ball-and-stick drawing, showing which files referred
to which other files. The purpose of showing this to
people, is so they won't be tempted to just "erase"
a part of a single file, because that makes the file
set "inconsistent". And there will be trouble. In the
case of your database project, there's only one database
file. So edits to the database, only have to be internally
consistent (and for the same reasons as in the Firefox case).

The Windows.edb, the dumper converts it into *40* files.
To give you some idea how complicated it is. And just
two of the files, allow you to create a list of
scanned files to date. Some of the files are
huge and contain the inverted search index.

Paul