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