h a l f b a k e r y
Futility is persistent.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
or get an account
All files are in one single folder (duplicates from different
folders are distinguished with a uniqueid.
Each file has a user remarks field and a history of changes.
You can create a "version of structure" and move the files
around or clone copies of them in various "paths" (similar to
keywords) and also give the files hierarchial
keywords dependent on the structure version.
If you want to see your code organized under src and the
binaries under bin, you can simply "move them around" and
arange your "directories" and "files in the directories" to fit this
Then if you want to create another model of how and where to
find your files, just create a new structure version (based on
the old one) and move files around, delete them or change their
You can always go back to the older file structure. You will be
warned if a newer version of the file exists in a different
structure version and if you wish to update. (or if the file was
deleted, and if you wish to delete it here too).
You can always go back in versions and find the older versions of
the folders and directories.
Programs running on your operating system will only see a
filtered version of the folder tree with the structure version you
choose, and with the keywords (or labels) under the hierarchy
that you choose with a whitelist and a blacklist.
The UI to look at this will show you grayed out folders and
directories that are not in your current choice.
"In this era, programmers were much cheaper than computers." [8th of 7, Apr 12 2018]
||UNIX fs's do most of that, natively. You can set up quite a nice relational database directly on the file system.
||Thousands of years ago (seemingly) the IBM s/36 could do something very similar... the filing system was almost an rDBMS in its own right, which made it trivially easy to create quite powerful tools with a small amount of JCL.
||I can name one thing a whole bunch of eunuchs
||Ive always said that folders are bad and tags are
good. If you have a big red thing and a small blue
thing where do you file the big red thing: the
folder for big things; or the folder for red things?
Either choice, youve guaranteed theres a 50%
chance youll waste your time later when you go to
look for it in either the big things folder or the red
things folder first.
||Keyword tagging (and other
derivatives, such as favourites and hearts and
colour-coding in modern consumer-oriented leisure
operating systems) allow you to just have one big
soup of files and packages without needing to file
things away (until theres no more of it,
||I have wanted such a filesystem for a while, specifically for
Google Drive. I really like the way categories are used on
Wikipedia: Any page can be in any category or categories,
and any category can be in any category or categories.
||So, would this idea be filed under "catagorical" or
||Id suggest a rat-tail file.
||There are times when I want to know something
about the file structure and not the file contents.
||So have categories to categorize your files by structure,
like Wikipedia has categories for lists and categories for
pages that need certain tasks done. Right? Or by "file
structure" do you mean the hierarchy? Because categories
can do that, as I said above.
||However, for files that make up software, like those in
your operating system folder, hierarchical or some kind of
database is probably still better, because they're
accessed by the computer far more than by the user, and
that would be eased by it.