|
|
|
|
#1
12-02-2012, 11:43 AM
|
|||
|
|||
|
It's true that if you link files and then move the folder they are in outside of UR, you would have broken links. But if you always keep the files in sub-directories of the same path as the UR database, you can synchronize those folders to UR and never have broken links:
http://www.kinook.com/UltraRecall/Ma...ronization.htm Linked files ARE searchable by UR (assuming they are of a supported file type like text, html, pdf, etc.). Quote:
|
|
#2
12-02-2012, 02:37 PM
|
|||
|
|||
|
PureMoxie, thank you very much for this double info that both look very encouraging.
Sideline: I tried to understand the help file bit you thankfully linked to: Another example of very abstract style with which I have very big probs - which gives me a new: I did NOT understand this help bit, except for the fact that I clearly understand it's proof to what you say (not that I doubted) - I suppose that if I didn't just look at it for some minutes, but for 70 min. or so, incl. doing heavy notetaking in all the bits referenced there, I would understand much more of it (but not necessarily so). Hence, my idea: This UR help file style, evidenced in your link, is very certainly very high-brow, and it demands lots of intelligence to write in this style (= another element in my thinking that whatever you ask an IMS to do, kinook is able to deliver it (which doesn't mean, as we all know, that they are willing to deliver it). But: Many a people do not understand it, or do (partly or wholly) understand under the above-described circonstances, 70 min. or so for just a little bit. This means, kinook seems to deliberately try to restrict the access to this fine (but not yet optimized in every detail) prog to very intelligent people, and were it not for the forum, kinook would even succed in this policy. In other words: By writing some 12 lines (in this case), instead of writing perhaps 40 lines but that would be immediately decipherable for us ordinary people, they would succeed in making UR's fine functionality available to many people, whilst today, they succeed at limiting its scope to sort of an elite - how many people are willing to surf around 70 min. (or make it 50, and then perhaps abandon) in order to understand just ONE bit of its functionality? Ok, some people could then tell me, well, that's your prob, you're just dumb. Ok, I'm willing to accept that. I've said this, my IQ is about 120, not more. But then, many people are just "average" here, 100, 105, whatever, and would like to better organize themselves notwithstanding. Does kinook hate these people, or is kinook just unable to see it closes the door to all these people to begin with? The same goes for my ideas re opening up UR to a little bit of real office use, incl. doc M (have a look at Treepad Enterprise: they have access M for workgroup needs (but Treepad is a very special case, not even an English-speaking forum, but a Portugiese/Brazilian newsgroup (no, that's not a joke))) - UR, with the current help file (and weirdness of some commands), couldn't hope to be implemented in many offices as a workgroup's general working tool, since the people working there, simply do NOT understand how it all works. So there's call for action here. As said here, a long time ago, it's outright crazy to organize a "competition" for a better help file in which the first price is 200 dollars, or was it a free Prof licence? On the other hand, if kinook DID real development again, and development that would assure UR, at the end of that (not-to-be-interrupted!) process, to become absolutely first-rate in every respect, well, I think that some UR users would indeed be willing to collaborate on such a help file AND accessibility of commands rehaul (both are needed), in order to get really top-notch sw. So, in the end, we do NOT have a catch-22 situation, but just lacking good-will, it seems, and with that good-will entering the arena, lots of progress should be able to be achieved. Back to topic : a) If I understand well, there is linking, with the synonym (?)of "attaching" (attachment), and there is embedding, with the synonym (?) of importing, so we have 2 concepts here. b) Both allow for indexing of those files that can be indexed by UR (so there is no difference in this respect?). c) Embedding/importing will blow up the db, of course, whilst linking/attaching, of course, will not. d) So, the only (???) reason to embed/import would be, avoidance of possibly broken links, e) but if you pay close attention to what's be needed to be done in order to avoid broken links (= the help bit I didn't understand but of which I'm happy it exists, meaning "it CAN be done (if you understand how, which is the real challenge here)"), you can avoid these, even with the linking/attaching. f) Thus, except for special cases where people would like to exchange specific UR db's containing "all the stuff", instead of quite simply transferring the UR db plus a certain file system folder, with its content: As long as you pay attention to do it right, prefer linking/attaching, since there is no further advantage with embedding/importing, but the big prob of it blowing up your db. g) Just my assumption: In order to get the respective elements from these indexed, "attached" files, out of the UR index, when moving these files away from these "UR attachment folders", you should not process them (also for renaming and for deleting) in the file system, but from within UR. I hope this is all correct. (As said, without understanding the respective help bit. As said, that's my "fault" - not smart enough -, but it's UR's prob: Not enough customers to be on par with UR's demands on them - this is "better" even than an asking price of 2,000 dollars barrier if you want a prog stay elitist.)
|
|
#3
12-02-2012, 04:11 PM
|
|||
|
|||
|
Any file item can be linked or stored. Even imported files have the option to only be linked.
Let's say your UR db is in c:\data. If you put files in c:\data\files, you can then link to those and even if you move the whole c:\data directory somewhere else, the links will be maintained. Whether to link or store really depends on what you are trying to do. There is some benefit to having your files stored in the database, because then you can back up or move only the UR db and still have all your files. However, if you are dealing with thousands of files, prefer a single UR database, and are disciplined enough to keep everything in the same directory path as your database, it seems to make more sense to link.
|
|
#4
12-02-2012, 06:19 PM
|
|||
|
|||
|
"Let's say your UR db is in c:\data. If you put files in c:\data\files, you can then link to those and even if you move the whole c:\data directory somewhere else, the links will be maintained."
That's as you'd expect this. Of course, this doesn't resolve problems by renaming. (I, e.g., do lots of renaming, because of adding / changing multiple "tags" in filenames (I have stopped to do them as "comments" within ntfs metadata). "Whether to link or store really depends on what you are trying to do." That's confirming what I said. But you mention another aspect, which is backup. Since UR doesn't offer versioning (yet), even for backup reasons, it could be preferable to have these files stay external, and let your synch routine doing the rest, incl. versioning within your archive folder. "Any file item can be linked or stored. Even imported files have the option to only be linked." OMG! PureMoxie, I'm generally not into semantic nitpicking (cf. the reprimand I get when in outlinerswforum I dared use the terms "programming" and "scripting" as synonyms when in fact all I wrote about was scripting), and I'm grateful you try to clear things up, here, with me, but in this extreme case, please allow my asking again: "Even imported files have the option to only be linked." - huhhhhhhhh???? Meaning, I don't even understand what that could mean, besides the fact that I try to distinguish the different possibilities by their respective terminology, too. And btw, UR seems to use "store" and "import" as synonyms, but I also discovered another term (I cannot find again, on top of all those to be found in my post above). So there remains some semantic chaos, for the time being!
|
|
#5
12-02-2012, 09:28 PM
|
|||
|
|||
|
PureMoxie, not quite. UR doesn't recognize that files have been moved but rather considers the file to have been deleted and recreated elsewhere. You can see this by adding Item Notes to a linked file. On moving the file to another subdirectory the notes are lost. So then UR just functions pretty much like an explorer window with file searching capability. On the other hand, if the file is not going to be moved then linking it elsewhere in the outline become very useful.
|
|
#6
12-03-2012, 01:37 AM
|
|||
|
|||
|
Then I suppose the same is true with renaming?
In a general, this absence of even simili-monitoring of changes (renames, moves) in the file structure, of "managed files" by the prog in question (UR, MM and many others), is extremely unhandy in everyday use, and worse, it's annoying because you perfectly know how easy it would be to implement this simili-monitoring. I perfectly understand that real monitoring would be a little bit over-the-top, i.e. to ask from such an "external" prog (= external to that file format) to monitor file changes done within the file system (from your file manager, or from within the native prog of the given file type) - in fact, good synch progs (GoodSync and Syncovery (ex-SuperFlexible) do this, but of course, they are specialised in such a task - as said, you wouldn't expect such functionality from UR, MM or such. But simili-monitoring should be possible! In fact, there isn't any monitoring involved here, you, the user, just refrain from ever make changes (rename, move) to such a file (= linked by UR or MM, etc.) from both the native prog of that file (!), and from within your file managers, and you'd do any such changes from within UR / MM only - which is unhandy enough. But under this condition, it should be possible to avoid broken links from within such progs pretending to have file M functionality, too. Btw, would be interesting to know how TB handles this task, in view of the fact that TB outrightly advertizes the file M capabilities of the prog. As said, I very often rename files, especially those I'm working with, and so I've got a max of broken links in in AO and MM (or if I switched, in UR and MM), the most nasty problem here being that you cannot see from the link target from where (or IF, to begin with) it has been linked to. That prob should not constantly spoil our "working experience" 30 years after the intro of the pc. And after all, it's not even simili-monitoring. It's simply that these prog miss a function that updates the link when the prog "KNOWS" the link should be updated, since, as said, you'd do the rename / move within that very prog. Oh yes, and then you link to one file from 2 progs, and get probs nethertheless... It's all the fault of MS; such functionality should be implemented into the file system (NTFS), and not every single applic showing its limits. Btw, this very prob of broken links, even with native .lnk links, got me abandon my clones-within-the-filesystem system, thus my "tagging" (= codes in the file names), and hence my need to rename files again and again. Anyway, it's so big a prob that in my numerous files, instead of linking, I just do "SEE xyz", with a description of xyz that will hopefully remain valid even after renaming xyx a little bit, and then I rely upon quick access by entering the starting chars of the file name within my file manager - a good folder system (and in which "standard" folders are accessible by one key pressing) helps here. But it's all so cumbersome for us, because "they" do it all so amateurish. No reliable links, 30 years into the pc age, that's devastating. (Hence, the upblown db's, linking avoidance because links are managed so badly.)
|
|
#7
12-03-2012, 10:21 AM
|
|||
|
|||
|
Quote:
It would be interesting to see if having two synchronized folders in UR would allow moving a file item from one to another - within UR - while maintaining the UR record and also moving the file on disk.
|
 |
| Tags |
| address conflicts , importing , resources |
|
|
Hybrid Mode
