Best of Both Worlds, Twice - I think this was the missing element to a perfect system: The "one db, one tree" nexus is dead.

Posted by 22111
Dec 21, 2013 at 12:36 PM

The above discussions mixes up two or three different concepts.

First, we have dedicated file managers / file commanders. Here, you chose the directory/folder in your file system (internal hdd or external devices), and will then get a list of what currently is in that directory / folder, those entities can be original files, or links / link files, e.g. .lnk files (XT); I don’t know if the most recent Windows links are necessarily files, too; technically, it would be possible to just have link entries in the file system which are not files on their own.

Variant: If you want to gather “project files”, i.e. various files from different locations/directories, you create links to them, and which you put then into a new directory named after your “project”, and which is a regular Windows folder which can, of course, contain such links / link files, and also original files; you can even rename the links (but not the original files, without breaking the link), or move/copy them to other folders.

Then, there is a variant, present in some of these file commanders, virtual folders. These file managers do not create .lnk files or such but create proprietary databases for files from any folder, from which then they display the db entries within a quite regular “lister”, as they would display the content of real folders, and their specificity is that you only see those “virtual folders” from within the file manager from within you will have created those “virtual folders” and their respective “content” (= internal, proprietary “links”/references to real files) - this is all rather basic, and I believe I remember that ordinarly, the entry in the “virtual folder” is not updated together with a rename/move of the original file, but this “breaks the link”; this might not be the case today in every such program, though.

In practice, this concept appears much less productive than it seems to be “on paper”; I tried with every such file commander (not only for some trial days: I own some 5 or 6 paid ones, and then some free ones, too), and it’s simply not worth it imo.

Then we have IMS’s, outliners or other, which “read” files into their tree, their db, or whatever. Here again, we usually do NOT have a precise real-time “image” of what’s in the file system, within a given folder, at any given moment, i.e. there is not, as is in dedicated file managers, an immediate reading of the file system entries, then display of these entries. There has been a little “discussion” in the Ultra Recall forum of you follow the link to the original thread within this recent UR thread: http://www.kinook.com/Forum/showthread.php?t=5219 .

But there again, you must differenciate between “just linking” which in UR’s case means creating a link ITEM for this (which is the reason it takes some moments), whilst in fact, you also could imagine just a “list entry” within the tree, and the creation of a link item only then if you need that for entering metadata for that file (the abolition of ADS metadata within NTFS is catastrophic in its consequences for everyone, but then, Mr. Balmer or Ballmer did not do anything intelligent in his entire MS life, except for his own income), so real-time updating this could be speeded-up.

As said before, UR has two ways to do this, just linking (but with creating a link item for any such link, hence it’s not that fast here), and another concept, importing the TEXT of that linked file (Word, pdf, some other formats) into its freshly created link item, if you set its setting for that import that way, and in this scenario, you can search the text of the “just-linked” doc from within UR, which in many cases is a very good thing - similar to TheBrain, where also some users use the IMS tool as a reference tool for thousands of pdf’s. It goes without saying that in THIS case, importing/reimporting/synching a (big enough) folder to UR “takes hours”, as has been said above (recreation of those parts within the UR index).

As I have said before, there would be a lot of synch work, and of maintenance for making this possible (renames/moves of linked files when UR isn’t running, e.g.) if you tried to synch files - it’s all very much easier when you just LINK to FOLDERS, BUT THEN DISPLAY THEIR CONTENT, this is not mutually exclusive, on the contrary - but such a concept implies that you do your “internal/further” linking within the file system, not within the IMS/outliner, i.e. an optimized UR would fetch the contents of your folder c:\abc every time you “go” to that “folder link item” in UR, and display all its content, incl. any .lnk files in that folder.

Now for what Stephen says about TheBrain - I do not doubt that all this is correct, but we are not informed how exactly TB “does it” (whilst I explained here how UR “does it”), so some further explanation on this would be very helpful.

As implied above (it becomes evident from the thread linked within the linked thread), UR does not do the synching automatically (and doesn’t monitor renames, let alone moves), but starts a manual synch by keyboard shortcut, and that’s my point:

Whenever an IMS is not able to monitor file system changes, any moment (e.g. by having a little add-on that’s running anytime, even when the IMS itself is not running, then synching between this and the IMS whenever the IMS starts to work), you will quickly end up with de-synch, so this should be avoided imo, cf. what I described some weeks ago - it’s perfectly possible to INTEGRATE a REAL file commander into your IMS, and that’s then quite another thing.

This being said, UR’s “manual synch” is not that bad, it’s so much better at least that most competitors in which there is no such synch function, but where you would have to update all your links by hand - my current system is to display the respective file folder, in any file commander of my choice, together with the respective outliner folder, i.e. a macro checks if I move between “siblings” and such, in which case no new folder display in the file manager is needed, or if I “change” the respective folder, and then my file commander displays two folders, side by side, which is not technically necessary, but which I did in order to see “how it all works best”, also in a possible corp environment:

In the left pane, I show “sibling” files, and current ToDo files, i.e. I apply two or more filters to a folder containing a 4-digit number of “standard” files, and in the right pane, I show “relevant” files, i.e. the file manager displays the respective sub-folder containing files “relevant here” (= original files or .lnk files, I always work within XP), which in my system is “external files”, files from the web, downloaded pdf’s, and all such (btw, when such a “deep” folder doesn’t exist, the macro displays the folder “1-up”, or, if that’s non-existent, too, an even broader, more “general” folder for that subject, and so on - you certainly get the interest of such a concept for a corporate environment), whilst in the left pane, it’s the “self-created files” for the same outliner entry/category.

I divided up those “files to consider here”, into two different folder systems, because I think that for “internal files” (= my left pane), you need much more security than for “external files”, so why not have them managed by the same macro/script/program routine, but from different physical sources (and as said, my separation into “one big folder, then filter” for “internals”, and “deep sub-folder file sub-system” for “externals” is only in order to experiment with both concepts; in the end, you could choose the first, or better, the second one, for both kinds of files); as said, there should be an “end product” where you would not have links for display in a file commander, but real-time display, file-commander-like, in a frame/list within your IMS itself, together with the immediate siblings and links within the outline body; entries from several sources, put together in a breeze, and divided up there by separator lines, e.g. - I call this “natural hoisting”, i.e. separation of the tree from your immediate working environment.

Again, it would be of high interest to know exactly how TB does linking/referencing, for single files, and for folders, respectively, in order to see where it currently stands between “regular outliners” and dedicated file commanders, and especially, where might be its possible advantages here over UR.