Difference between revisions of "FilesDB"
(Νέα σελίδα με ' = FilesDB — utilities to handle file metadata = == Data == The following data should be stored for each file: * name * size * full path (relative to scan point) *...') |
(→Commands: Add rescan command) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
The following data should be stored for each file: | The following data should be stored for each file: | ||
| − | * | + | * path |
* size | * size | ||
* full path (relative to scan point) | * full path (relative to scan point) | ||
| Line 12: | Line 12: | ||
* extension | * extension | ||
* dirname | * dirname | ||
| + | * Scan identifier | ||
Less useful data that can also be stored: | Less useful data that can also be stored: | ||
* permissions | * permissions | ||
* dates (creation, modification, access) | * dates (creation, modification, access) | ||
| + | * owner | ||
Each database should also keep track | Each database should also keep track | ||
| Line 24: | Line 26: | ||
(for example, more hashes may be added in later versions), | (for example, more hashes may be added in later versions), | ||
so the data storage should take this parameter into account. | so the data storage should take this parameter into account. | ||
| − | |||
== Commands == | == Commands == | ||
| Line 45: | Line 46: | ||
;sc|scan | ;sc|scan | ||
: scan a location and add to the database | : scan a location and add to the database | ||
| + | ;rs|rescan | ||
| + | : rescan a location and update the database according to added, changed, and removed files | ||
;qs|quickscan | ;qs|quickscan | ||
: quick-scan a location (ignore hashes) and add to the DB | : quick-scan a location (ignore hashes) and add to the DB | ||
;f|find|s|search | ;f|find|s|search | ||
: search for a file, according to criteria | : search for a file, according to criteria | ||
| − | |||
== Storage == | == Storage == | ||
Latest revision as of 20:12, 15 February 2019
FilesDB — utilities to handle file metadata[edit | edit source]
Data[edit | edit source]
The following data should be stored for each file:
- path
- size
- full path (relative to scan point)
- a number of hashes (md5, sha-1, xxh32, xxh64, git-sha, ssdeep, sdhash, ...)
- basename
- extension
- dirname
- Scan identifier
Less useful data that can also be stored:
- permissions
- dates (creation, modification, access)
- owner
Each database should also keep track of all the commands (scans) that were used to add content.
The data model should be extensible (for example, more hashes may be added in later versions), so the data storage should take this parameter into account.
Commands[edit | edit source]
The exact set of commands will be determined later.
However, the following should give a reasonable first approach.
The commands can be implemented as subcommands, like in git.
- h|help
- provide help
- v|version
- display the software version
- l|list
- list all scans in a database
- st|stats
- display statistics about the DB contents
- sc|scan
- scan a location and add to the database
- rs|rescan
- rescan a location and update the database according to added, changed, and removed files
- qs|quickscan
- quick-scan a location (ignore hashes) and add to the DB
- f|find|s|search
- search for a file, according to criteria
Storage[edit | edit source]
All the information is stored into an SQL database.
Individual SQLite files seem to be the perfect point between functionality and complexity, allowing all operations on data and easy transfer between systems.
All the command-line utilities should accept a "-d|--database <arg>" to specify the location of this file.