Questions about File Collections

[ghj]

Please excuse me for reviving this old thread, I have some questions the help file / manual does not answer. And my technical understanding goes not far enough as to deduct the information from the posts above.

The manual says that file operations (like renaming, copying, moving) can be done with the entries in the collection, but what about the original files, in different scenarios?

1. Original file (in its original, "physical" place) renamed: Will the new name show in the diverse collections this file is listed? (It's evident that is always wanted.)

1a) Ditto but rename within a collection: Will the rename there replicate to the original file? (It's evident that is NOT always wanted, but in most cases.)

1b) Ditto (as in 1a): Will the rename there (i.e. in the collection) replicate to this file's entries in other collections? (It's evident this is not always wanted either. Not doing this would only make sense of course when there is a NO to 1a).)

2a), 2b), 2c) for moving instead of renaming. (If de-synched renaming is possible, i.e. renames of the entries in collections, without breaking the link to the original file, it would of course be important for all links to be upheld, and changed accordingly for the move (new path for the link, i.e. for the collections / xml file entry), not affecting the list names, be they identical to the name of the original files in question, or some individual aliases, from renames having occureed in-between.)

3a), 3b), 3c) for deleting. Deletion of the original file should of course delete all occurrences in collections, too (previously renamed or not over there, in case such renames which do not affect the original file are possible), and deletions in collections should only delete the occurrence / entry over there, NOT the original file - but there could be a special control-delete (i.e. additionally) over there which would indeed also delete the original file, after a security dialog of course (even though you rarely press control-delete inadvertantly).

4. I hope very much for some of this functionality being implemented, would happily buy DO in this case. This would probably suppose that the functionality only works without fault when ALL the above renames, moves, deleted will have been done within DO, i.e. I would be willing to shift all of my file management to DO in order to have this functionality. But please state in case some functionality of the ones described even work correctly after some processing with other file managers, e.g. in special "monitored folders" or such.

From the posts above, I deduct that the user could implement that functionality (1)-3) and/or even 4)) themselves, with scripting and accessing the XML file, but since I'm not able to write such scripts, I would like to have at least some of it ready-made, in a file manager I can buy in order to have that functionality.

Please forgive my questions, instead of just trying it all out with dummy files, but in case this functionality has not yet been implemented, I would like to be able to trial DO at a later time when this functionality will (partly or fully) be there, and trialling DO now, without knowing, would prevent my possibility to do so later on.

Thank you very much!

[ghj]

Oh, sorry, I left out an important aspect in my questions. What about folder entries in collections, are they possible, and in what respect would they be functionally different from files, i.e. would there been functionality, described above, which would be available for files, but not (yet) for folders (renames, moves, deletes)?

(I suppose that when a folder is listed in a collection (lister), "opening" (by double click or by Return/Enter key) the entry could display the original folder, to which the entry links, in a/the second, regular lister, which would then work as any other regular lister.)

[Leo]

(I've split this into a separate topic as it's different and complex enough to be separate form the year old thread about other collection questions.)

Collections should notice changes made to files the point to and update to reflect them, as long as Opus is running when the change is made.

Renaming a file via a collection will rename the file itself, so it should be no different to renaming it from outside the collection.

Collections can point to folders, which works basically the same as collections pointing to files. If you double-click the folder, you go into the folder. Like double-clicking a shortcut to a folder.

Collections can also contain sub-collections, if you want a hierarchy of collections. So you can have them work in either or both ways, as suits different tasks.

If you have very particular needs for how collections behave, it's best to try your scenarios out and see how things behave to see if it is as you want. You can try Opus for free, and follow up here if you find something doesn't react how you'd like, in case there is a setting or other method to make it do so.

[ghj]

Thank you for this kind answer.

From the current help file of the OTHER program: "Paper Folders have a static nature. They are not sensitive to changes in the file system. Any stale items in a Paper Folder are automatically removed from it when the folder is shown the next time.
Exception: File operations performed on items in a currently opened Paper Folder will be reflected by the folder as if it would be a normal folder." - So this indicates that DO is very superior.

In another contender from Germany, where the file collections are called "File Containers", nothing is updated upon such changes either (just broken links all over), and over there, it's not even possible to put folders in file collections.

It seems it's not any better with another contender from Greece, but for that one, I might be mistaken for most recent developments.

But you say, "Collections SHOULD notice changes made to files the point to and update to reflect them, as long as Opus is running when the change is made." - does the "should" mean that the replication is not entirely reliable if done in other file managers or by other means? Depending on what? Perhaps on bulk changes, i.e. changes which are made "too fast" one after the other, in another program / too much cpu demands from other programs in general when those changes occur, probably? So at least such situations / bulk changes would to be avoided by the user, and then they are sure those changes are properly monitored (and thus processed) by DO?

What about external hard disks? Are they monitored, too? Probably not? DO monitors c:\ only, but entirely? Or all partitions on the first internal hard disk?

Since your "should", it applies to those changes in general, i.e. monitored changes made by external programs - am I safe to suppose that ALL changes (renames, moves, deletes here, I'm aware though that even copies, for some users, might be within that list) are properly replicated WHEN made by DO, notwithstanding high cpu usage problems or other?

In other words, does DO do the necessary replications from internal code triggered from the changes, or does it monitor here as with external programs, so that there is a risk not every change (here, even done from within DO) is properly retrieved and thus properly processed?

In even other words, if I rename, move or delete from within DO, does this trigger internal DO code (which then triggers the respective change replication code), or do these commands trigger Windows code to do the work, upon which DO would then need to monitor any changes (made from external programs or from within itself), in order to process them, in a second step? (This would be only as reliable as would the general monitoring, right?)

If DO triggers Windows code, not its own one, does is work as described by me here, or do those commands - this would be ideal and perfectly reliable - first trigger internal code which fetches the objects to be checked for later, then triggers Windows code, then comes back to its internal code and processes the list it just has created, in order to do the replications?

As implicitely said above, it seems that DO is without contender in monitoring file changes, but is its replication of changes absolutely reliable in specified situations (changes made within DO itself, and/or on preselected drives (c:\ or others, too) to be monitored? Of course, I ask myself if DO does the monitoring by accessing the MFT table: Then, it would only work for NTFS drives, not FAT-formatted usb sticks. This in another example of a situation which be perfectly ok, but which would be good to know beforehand.

Btw, exactly the same problems present themselves for tagging programs, and I currently know not a single of those which would have resolved the problems of broken links, as DO has obviously done (but to which degree?) - not speaking of the evidence that trying to use a file manager and a tag tool concurrently is bound to fail in every given case.

This is not asking for tags and the replication for them, virtual folders - which, in order to avoid mixing up with Windows' "virtual folders" which really are "alias folders" - are termed Collections et al now - are ideal for me and should be ideal for most / any use cases once you know if or when they are perfectly reliable in being updated.

Or in other words, since you need a file manager anyway, perfectly-realized tagging / creation of collections (= in both cases subgroups of which the elements may be spread over the whole system) in a file manager is the perfect solution, whilst even perfect replication of changes within a tag tool would not do much good, for lack of integration.

[Leo]

Why not try it and see?

Collections should/will notice changes made by any other program, as long as Opus is running when the changes are made.

Opus monitors the filesystem for change events, so the changes do not have to be made within Opus for them to be picked up. I only say "should" because there are some cases where filesystem change events don't always work, which is a Windows limitation (and sometimes also a limitation of the device being monitored; e.g. some non-Windows network drives do not report changes properly, although I think they are a lot better these days).

What other programs do is of little relevance here so let's avoid talking about them.

If you want to check exactly how Opus will work in your environment with specific scenarios, the best thing to do is simply try them with it. That will show you exactly what happens, which will be more accurate than my assertions about what should happen. You may find everything works as desired; if not let us know what specific case doesn't work as desired and we may be able to explain how to make it work as desired. That's better than speculating.