UR using Too Many Resources

[gershonb]

Hello, I just got UR because the sample looked fun and I have some background in databases. I am enjoying being able to list all my website favorites and have dynamic links to things like google calendar, etc.

The problem is, UR uses a tremendous amount of resources, and its resource stack doesn't seem to be stable all the time. I'm on a quad machine with 8 gigs of ram. In Process Explorer (free download from Microsoft) I've tried setting the program's Affinity to run on only one processor. Still--it uses more resources than Skype, and Skype, bless its heart, is something my son the head programmer doesn't allow on the worksite because of resource problems.

Should I try importing just links rather than web content?

Any suggestions?
Gershon B

[kinook]

What resources are you seeing UR use a lot of? Right now on my box (Intel Core i7 w/ 8GB RAM), examining with Process Explorer, UR is using about 200MB virtual size, 30MB working set, 350 handles, 15 threads, 180 USER objects, 220 GDI objects, and negligible CPU, which is in the same ballpark as other GUI apps that are running (Word, Access, Process Explorer, Windows Live Mail, Firefox, Chrome). UR embeds Internet Explorer to display web pages that are imported or browsed to, and depending on the complexity of pages displayed by IE, IE itself might use more resources. Please send the info requested at http://www.kinook.com/Forum/showthread.php?t=3038. Thanks.

[armsys]

Hi Gershon,
Welcome aboard.
A simple answer: No.
It won't consume excessive resources unncessarily.
For maximizing Ultra Recall performance, try:
Ultra Recall is designed to handle large databases very efficiently (for instance, when populating the tree, only nodes that are expanded will actually be loaded from the database, the details for an item are only loaded when that item is selected, use of indexed searches, etc.).
But with items containing thousands of immediate child items or very large databases (hundreds of megabytes or multiple gigabytes in size), especially on older, slower computers, some operations in Ultra Recall can be slow.
Use a Local Drive
For best performance, store the .urd file on a local hard drive, not a network share or USB stick.
Items with Many Children
It is best to avoid expanding a node in the Data Explorer pane containing thousands of immediate child items, since loading many items into the tree can be slow and cannot be cancelled. Selecting the parent item is ok, because loading the Child Items pane can be cancelled. It's not very useful to expand that many items in the tree anyway. Instead, use a search to locate items of interest and select the item in the Search Results pane to use it. If you do expand a node with many children and UR becomes non-responsive, you can safely end the UltraRecall.exe process (using Task Manager) and restart UR without corrupting or losing any data.
Large Import Operations
When importing thousands of items or documents into a database (for instance, for archival purposes), rather than importing to Imported Items and moving all the items somewhere else later, import to the final location, since moving thousands of items in a large database can be slow.
Alternatively, cancel loading of the Child Items pane after a few hundred or thousand items are loaded (watch the Children: count in the status bar and press Esc to cancel loading), then select all (Ctrl+A) and move (Alt+L) those, and repeat until all items have been moved.
Updates in Large Databases
When performing update operations (importing, moving, deleting, etc.) on a large database, there are a couple of settings which can increase performance.
A) Adjust the SQLite synchronous level
Ultra Recall uses the SQLite database engine to store data in .urd files, which provides robust data management to ensure that your data is safe. Better performance (up to 50x faster for some operations) can be achieved by disabling the synchronous flag, but be aware that if Windows crashes or the computer loses power while UR is running, the database could become corrupted. Always perform regular backups of your database.
To use the fast SQLite synchronous level, extract and double-click UseFastSynchronousLevel.reg in the attached ZIP file, and restart UR. To restore the safe synchronous level, double-click UseSafeSynchronousLevel.reg and restart UR.
B) Disable Undo/Redo
Some update operations can be much faster if Ultra Recall's undo/redo feature is disabled. Undo/redo can be useful during normal use, so you may want to disable it only when performing large import or update operations.
To disable undo/redo in Ultra Recall, extract and double-click DisableUndoRedo.reg in the attached ZIP file, and restart UR. To enable undo/redo, double-click EnableUndoRedo.reg and restart UR.
Note: Use of these options requires Ultra Recall v3.2 or later.

[armsys]

...I've tried setting the program's Affinity to run on only one processor.
Tweaking the CPU affinity is a wrong direction to maximizing the UR performance.
Instead, disable prefetch and remove virtual memory.

The unusual heavy activities of UR may suggest the URD (ie database) is potentially corrupt. Relax. You won't likely lose any data. Just run Tools | Compact and Repair...
*** CAUTION *** Please read online help first re: Tools | Compact and Repair....
Let us know your result.

Import links instead of full content (aka webpages) whenever possible. Otherwise, you're overloading your UR unnecessarily.

Hope you're happy with your UR.

[schferk]

Very good advice, armsys, and only some of those I had read earlier. Very helpful indeed.

Now, for the risk of appearing dumb as far as I'm concerned, let's clarify for new users or people like me who haven't been too much interested in importing otherwise than text content, with some pictures / graphics here and there, but muse what could be possible, otherwise - I might be mistaken in what follows:

In UR, there are 3 ways for processing content:

a) Just link. In this case, content is not indexed, hence not searchable from within UR. This might be the case for linked .mht's, and linked .pdf's - or are just-linked pdf's UR-searchable? Or, is no such external file indexable here ? (but see b)

b) Embed. With embedding, an external file stays outside of the UR db, but is linked, and its content is (necessarily? or are there other indexed

c) Import. Here, the external file is stuffed into the UR db (which means it will bloat it, etc. - so in any case we don't miss something by just embedding, embedding is preferable to importing, so why ever import a file into UR to begin with? but see below).

In this case, everything (?) is searchable? Probably not, since UR presumably doesn't "know" special file formats, which it can import = stock, but not index. So, which file formats are indexable here? I suppose .mht (?), and certainly .pdf, right? Also, Word files, I suppose, .txt, .html, .rtf?

If I understand well, both b and c will have the same indexing characteristics: a file format that is indexable in b, is indexable (and that always means, searchable) in c, too, and vice versa - but is that so?

And, if I understand well, the only (?) advantage of c over b would be that the external file will be exported within the corresponding UR sub-tree, whenever you export that, since it's contained in it; on the other hand, embedded files would need to be manually moved / copied within a folder that would accompany the corresponding UR sub-tree (= exported into a neb UR file), and any such file you don't move / copy, will produce a broken link within the UR tree, and worse, whenever you search for their indexed content, it will probably produce false hits, when in fact the source for these indexe words isn't there anymore.

Sideline: Even when you manually move / copy the embedded files in question, you'll probably get broken links, since the name and / or path of the corresponding folders will not be the same anymore - which makes me muse that perhaps UR could have have implemented a comman which would update the path, on condition that you have the folder name (= last part of the path) unchanged; this solution would help UR users to embed a max of files, instead of having to import them for the sole reason of them staying "transportable". EDIT: And there might be a routine implemented into UR that does "verify the links to embedded files within the selected subtree and list any broken links".

And finally, the sole difference between a) and b) would be that b) automatically indexes linked files and otherwise presents these b) files as the a) files, within the tree? Both would appear as links there, and it's just your knowing that e.g. Word files are indexed, that would make you know the link for file abc.xyz is not indexed, meaning it's just a link, and the link for file abc.doc is indexed, meaning this link is an embedded file?

I suppose that there might be some people here in this forum that would be as thankful as I'd be to have all these questions answered, in a systemtic way, i.e. if somebody knowing the details of putting files into UR retook this schema a-b-c here, but with the respective corrected info in it.

[armsys]

Hi schferk,
I know one day inevitably I'll come across your mentally consuming verbose manifestos.
I'm terribly sorry: With due respect, I get lost once again. What are your points?
Please indulge my curiosity:
1. How much time do you spend to compose your prolific manifestos here?
2. Have you actually ever exercised due diligence in experimenting with products before publishing your magnificent manifestos here? For example, for RM, have you actually tested your RM dashboard(s) with topics/tasks embedded in 30 or more respective mission-critical mindmaps?

[Nobodo]

ROFL!

I still come to the kinook forums occasionally just to see if there are any new books that have been recently released. :p

[schferk]

RM
Have answered in due place.

Composing time
Above answer cost me 35 min. incl. the time to develop my points. When in focus, I often think rather fast, and - and here's the quirk that makes reading me strenuous -, while writing, I also catch all the relevant little details from my mind in order to "complete" the sub-subject as far as I'm able to do that, at the time. I also do not revise then, in order to bring it into better order, leaving the sub-details slightly misplaced - the reason for this is my knowing that further on, I'll get a better grasp of it all, which will then invalidate some of my points, and some day indeed, I should put it all into the right order - when I'm not any more in the groping-around stage. On the other hand, even this intermediate stage brings enough new insight that's worth to be shared; I judge this from what I otherwise find, in the web, and in publications available to me. It's also about ordering knowledge, and systematizing it, whilst anywhere in the web, the good things are enormously scattered, and with very big holes in between.

Back to topic
I know there is the help file. I admit I have developed sort of a phobia vÃ*v the UR help file, and I remember that of course there is some info that could inform me about some aspects of my question. But then, it has decidedly be my intention to ask like a newcomer to UR would ask: 1, 2, 3: 3 different kinds to put external things into UR, or to just link them to UR, and have it all together, one by one, from the lightest way of "connecting it to UR" down to the "most integrated" way (but which, for its blowing up the amount of date in UR, hence rising answering times, and even perhaps, at some point, stability probs, should be avoided whenever possible).

So a new user of UR, or a prospect for UR, would like to have such a COMPREHENSIVE account of this part of UR's functionality, from HIS point of view, i.e. deciding, which kind of external stuff can be put into UR in which way, and thus, what will I decide upon this kind of external stuff, and of that... and of course, such a comprehensive "simili-table" would also make evident any sensible but missing functionality that UR might have, at this point.

So here again, it's about systematization of knowledge, here about a CORE feature of any such sw, i.e. "how to store things in it, other than text". Please imagine a UR prospect: At this time, he's forced to get this basic, essential info from driving forth and back in several help file items, and even after this dreadful voyage, he probably will NOT be able to make the above-tried systematic "table", but will be in doubt about more than one detail here.

Hence the utmost interest of UR to provide that thing that I have tried to begin above, and where I certainly will have made numerous errors. But's it up to UR to clarify UR for new users, in order to make it a never-ending IQ test for every possible new UR user to gather his knowledge about UR on his own, and for every such prospect (or worse, new user) again, and again - that's a lot of extravagance UR shifts upon its (potential) users.

And since UR doesn't seem to see the urgent need for a better help file - of which my beginning of a systematization was only an example -, it would be so kind if experienced UR users helped all of us out here, took what I wrote above, put it into a new entry form, and weeded out any of my numerous mistakes and possible misconceptions there.

[armsys]

This time your 35-min. manifesto is barely manageable within my humble intellectual capacity.
By simple mathematical interpolation, your other manifestos published on this forum could range from 90 to 120 minutes.
Logically, it comes to 3 intriguing questions:
[1] What's your income-earning profession?
[2] Due to your peculiar writing style, are you a German?
[3] How come you leave no cyber footprint on the internet?

Apparently you missed the answer to your oft-mentioned RM vs. UR.
I appreciate you share with us your methodology of how you develop and organize your ideas when composing your magnificent manifestos here.
"Order" appears 6 times in your above manifesto. IMHO, on the contrary, UR never promotes order per se. UR is an unstructured database, save some basic attributes.
Regarding my UR learning, I actually took extensive notes from the entire online help on the Ultra Recall. Most "info items" are heavily tagged with "keys." Every year, I return back to my URD (UR database) exclusively on Ultra Recall to review the entire knowledge. That's exactly the 5th year what I'm doing now. And I'm still learning.
Sincerely hope you enjoy using your UR.

[schferk]

What I deception!

I came back here to get some (even intermediary) development on this link-embed-import theme, but nope.

(I admit that (both) my mother('s) (t, God save her soul) language were/are German, whilst I'm not, and since I never spoke English in my whole life, my composing posts in English gives me some English writing practice at least, especially if I try to write fast (there's also the electronic version of Langenscheidt Handwörterbuch ever-running that I consult about 2 to 3 times the half-hour - 120 min. would mean a very long post, though, or 2 consecutive and rather extensive posts with a little, not "thinking", but "thoughts-breeding" time, in-between.)

"Apparently you missed the answer to your oft-mentioned RM vs. UR." and ""Order" appears 6 times"
Answer in due place

"took extensive notes" and "Every year, I return back"
That's what I mean, every user has to do this work on his own, since there is no such consolidated knowledge made available by the help file, but only scattered details (with rare exceptions), and not speaking of the UR phenomenon (I have never seen in such an extreme nature elsewhere) that you travel around in a closed set of multi-referential dead-ends NOT containing the crucial info anywhere, and without knowing where the info might be out of this self-referential set. And I said, why forcing everybody to do this work for himself? Why not make it available once and for all, even by way of a collaboration here in this forum, and then it's set, instead of anybody having to do the same aggregation work again and again. Besides, I'm just a little bit angry here since I've clearly made my point long ago, and though, I'm forced to repeat again and again - your saying how you do it, is just ANOTHER proof that the how-to's of UR are so unintuitive that only regular revising what you labourously collected for you holds it all together somehow, makes it available again, more or less.

I brought a very good example above, and in spite of my explaining what's the interest in ordered aggregation here, collaboratively (and thus avoiding indidual mistakes and misconceptions, if every user is out on his own), you simply repeat, between the lines, that is has been so forever, chacun pour soi, and so be it further on!

Another example is that weird "first steps" problem, where UR newcomers don't easily get how to do siblings and children, for just normal, basic content items, but where they wonder a long time (or quit, in-between) how all these different templates might function together, and I remember very well my very first try with UR - I even deleted the trial since I thought it was broken! (I had tried desparately to get content into a template that's not for content, over many minutes, and by all means possible - was also a problem of the terminology employed for the different templates.) And to say the truth, I got also more and more fed up with UR because I simply didn't get some concepts, even with (some simili, some real) help in the forum, let alone my wandering for hours over that caricature of a help file), and whenever I had "got" something, but for a function rarely used, a month later, I hadn't the slightest idea left how to make that functionality work I knew was there - so much for the "intuitiveness" of this prog. On the other hand, I say, it's rock-stable, and I know what I'm saying, my db having exceeded 1 giga, whilst in MI, for db's of 30 mega, lot's of crashing, lotsa a time.

So what I'm saying here, I KNOW about the real advantages of UR, but I'm getting more and more disappointed with the general rule here, from kinook AND from forists, that these things might stay unshakeable, but see, for most possible users, it's very simple:

For them, functions that are implemented in so weird a way that they cannot access them, cannot make them work for them, are simply as "good" as are function that ain't there to begin with. And that, for many a prospective user, puts the "value" of UR, from his subjective pov, into perspective, and in a very unfavourable way for UR: He gets hand on just SOME functions, the minor ones, of UR, doesn't get to the elaborate ones - and so, he's back to his starting position where he compares UR to 30-bucks outliners, which on top of that, even for the basic functionlity (see above), are much more "accessible": No need there to make your aggregation of the "help" file topics on your own, and have numerous cheat sheets on hand, just in order to do quite normal things with your IMS, there!

So, fellow posters, by repeating that it's each individual's own duty to individually cutting his way thru this jungle, you will NOT improve UR's current market position, and hence, there is quite little chance that UR's slow development - of which many here ain't happy, and say so - will ever accelerate - whilst collaboratively making UR's functionality much more available to prospects that it currently is, could at least a good step in the right direction, especially if kinook motivates current users by doing some necessary developing work (typical example: UR comes along "high-brow". Then there isn't formatting in its tree. But, thanks to his "high-brow" impression he gets from this prog, a prospect will blame himself for not finding the according function, when in fact it's not there. So he will spend a lot of time searching when it would have been much better, marketing-wise, to let him know, outright, that formatting in the tree is planned for next year only. People love such straight info that spares them a lot of time and frustration).

But then, I often think I'm speaking to a stone wall and better had let it go: I've too much having to repeat myself here, and with no result.

[armsys]

Vielen Dank für Ihre Antwort.
1. Annual review is uniquely my study habit, which is hardly applicable to other users.
2. I'm a contented user of UR.
3. I find the UR online manual useful and helpful, IMHO.
4. Please kindly name an online manual whish is distinctively better than UR's. Enlighten us.
5. I don't detect any connection between "chacun pour soi" and the UR, but I respect your view.
Have a niece weekend.
Enjoy using your UR.

[schferk]

armsys, there's a problem, you ferociously deny KNOWN probs of UR (cf. the web and what people say about UR's accessibility to them, and that's generally the main reason they refrain from using it, otherwise it'd be a more than highly competitive product). I'm not entering your little game who's right and who's wrong here, I'm simply trying to EXPLAIN why people react to UR, in big numbers, as they do, and when I bring examples, it's like I had never written them down.

Such a denial, against the outlined facts, doesn't help the product you are ineptly trying to defend, and which in fact, by constructively critisizing, I potentially (if my voice is heard, that is, and which you try to combat) defend much more than you do, by instigating the actions that are highly needed in order to overcome this double virtual standstill (in sales, in development - a last word here: Those people that are able to COPE with the very special style of UR, already bought it, years ago: meaning, for broadening the customer base, UR has to make accessible its fine feature to us ordinary people, too - or let's face it: some people like elitist programs, and don't like that the plebs will gain access, too, because then, they can't feel as elitist as they felt before - and this variant does certainly apply to some), and in order for you to understand me, I'll make a last try:

You have bought this sw, and you like it. That makes 1 buy, and 1 update here and then. The problems I describe, mean that THOUSANDS of people who consider UR, do NOT buy this sw. So, when you succeed in convincing kinook and forists here that there AIN'T the double accessibility (gui, then "help" file) prob I describe, that means that nothing will ever be done about this problem that every year costs UR perhaps 1,000, perhaps even more prospects refraining from buying UR, which they would otherwise have done.

And this means that for one paying customer having his way, kinook misses about 1,000 sales a year, which means, Standard and Prof combined, and assuming that 50 p.c. would be by bits, 250 Prof 25,000, 250 Standard 12,500, 250 bits Prof 5,000, 250 bits Standard 2,500, sum total 45,000 bucks a year evaporated instead of going to the developer.

I suppose that would pay for LOTS of development - which in turn would bring many new users, beyond just bringing "back" those who too much feared the gui and the "help" file in order to buy in the first place. In a word, your stance potentially (= if you succeed in making others belief your sophisms that is, and so make them stay with their inactivity about it) HARMS the user experience of the rest of us. (And not speaking of kinook being happy or not with the proceeds.) And as for the "help" file, I've never seen any less helpful, so any help file out there is more helpful than this one, but instead of sharing your - as you say, at least partly systematized - knowledge with us, you hold it back. No problem with that, but don't make too many people believe that the current "help" file and gui (it's pleasant, but not intuitive) situations are good as they are:

No, the problems you deny are the main reason this product is not actively developed.

As said, I'm near withdrawel in front of such stubborn ignorance. As said, I'm in constructive thinking, and all this meta-communication where the output is ZERO, is very tiring, for the participants as for the bystanders, let alone the zero gain UR could get out of it.

But now let me be blunt: It will not be me who'll rewrite this (for us ordinary people out there) very unhelpful "help" file. So you better organize some collaborative efforts, or all your whining about disppointing updates will remain fruitless.

The point of departure ov this thread gone astray was system load and such, hence my question re external files and their storage within UR. My question hasn't got an answer yet, and from what I read elsewhere, I'm more and more afraid that UR doesn't offer 3 ways of handling external files, but only 2 ways: Just linking (with no update functionality, hence broken links), and with NO indexing, and then embedding, meaning importing, with indexing of SOME files, but at the cost of blowing up your db. Thus, lots of my description above was probably wishful thinking only, hence armsys stating he didn't understand, and I'd understand him, in this case. Or I'm too negative here, and UR's capabilities are nearer what I described above, than to what I describe here. All the more so a good reason to clarify what UR can do, and what it cannot.

A last word: If it's really an invariable fact that the "big guys" do rather few things, at the end of the day, instead of being developed in a way that after some years, they do almost all you would want them to do, why not going back to something lightweight, instead, and conceive your own hybrid system. In other words:

When there is really not so much to wait for, why then wait, in the first place?

Hope I'm wrong here.

[armsys]

schferk,
I appreciate your kind words.
I appreciate your utmost sincerity in helping Kinook to enhance the UR so that all users can benefit.

[PureMoxie]

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/Manual/foldersynchronization.htm

Linked files ARE searchable by UR (assuming they are of a supported file type like text, html, pdf, etc.).


I'm more and more afraid that UR doesn't offer 3 ways of handling external files, but only 2 ways: Just linking (with no update functionality, hence broken links), and with NO indexing, and then embedding, meaning importing, with indexing of SOME files, but at the cost of blowing up your db.

[schferk]

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.)

[PureMoxie]

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.

[schferk]

"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!

[seanferns]

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.

[schferk]

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.)

[PureMoxie]

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.

Thanks for the clarification. I rarely move or rename my files, so linking in UR works well for me. It's good to know all the caveats, though.

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.