Futilities/human: Difference between revisions
Tag: Undo |
|||
| Line 29: | Line 29: | ||
I might end up splitting FTS into multiple parts... | I might end up splitting FTS into multiple parts... | ||
See also {{l/sub|options}} | See also common {{l/sub|options}}. | ||
===Future=== | ===Future=== | ||
Thinking about how Nextcloud works has led me to realize its shortcomings and how overspecialized it is. I'm thinking that each piece of it can eventually be replaced by much more flexible tools. | Thinking about how Nextcloud works has led me to realize its shortcomings and how overspecialized it is. I'm thinking that each piece of it can eventually be replaced by much more flexible tools. | ||
I'm also repeatedly seeing the usefulness of having a searchable index of files that includes filename/path, timestamps, hash, and ideally the ability to tag files and folders with keywords -- all of which would be a key part of [[FileFerret]] -- and how relatively easy it is to create and maintain such an index using these utilities. (It also makes me wonder why there are, apparently, no filesystems with a queryable file database built in -- or, at least, a way to add one on.) | I'm also repeatedly seeing the usefulness of having a searchable index of files that includes filename/path, timestamps, hash, and ideally the ability to tag files and folders with keywords -- all of which would be a key part of [[FileFerret]] -- and how relatively easy it is to create and maintain such an index using these utilities. (It also makes me wonder why there are, apparently, no filesystems with a queryable file database built in -- or, at least, a way to add one on.) | ||
Revision as of 13:39, 20 October 2022
|
The Human Futilities
|
Purpose
The Human Futilities are a set of file-oriented command-line utilities, primarily useful for handling large filesets.
- goals: what these are for
- lib: class library
- ui standards: user interface standards and conventions
Terminology
- A file tree is a given folder and all of the files and folders inside of it.
- A file index is a collection of file-content hashes and the filepecs for the files that had those hashes at the time of indexing.
- A file collection is all the files referred to by a particular content-hash index
Commands
| name | seq | spider? | hash | description |
|---|---|---|---|---|
| FF | 0 | Y | - | find files by mask, date, contents |
| FCM | 3 | n | I | file collection merge |
| FIC | 2 | n | I | file index comparison |
| FTM | 0 | Y | n | file-tree mover |
| FTI | 1 | Y | O | file tree index |
| FTS | 3 | n | I (opt) | file tree sync |
I might end up splitting FTS into multiple parts...
See also common options.
Future
Thinking about how Nextcloud works has led me to realize its shortcomings and how overspecialized it is. I'm thinking that each piece of it can eventually be replaced by much more flexible tools.
I'm also repeatedly seeing the usefulness of having a searchable index of files that includes filename/path, timestamps, hash, and ideally the ability to tag files and folders with keywords -- all of which would be a key part of FileFerret -- and how relatively easy it is to create and maintain such an index using these utilities. (It also makes me wonder why there are, apparently, no filesystems with a queryable file database built in -- or, at least, a way to add one on.)