On application start, Collections tab is not populated until a user retrieves the collection list

[Searinox]

Creating a collection and then restarting MuWire results in it being absent from the Collections list unless another user attempts to retrieve the collection list. The collection remains saved in "\AppData\Roaming\MuWire\collections\local" in the user folder and appears to be re-loaded correctly. The UI listing gets correctly re-populated once another user attempts to retrieve the collections list.

[zlatinb]

I can't reproduce this, so will need your help.

1. Enable logging with the following line in logging.properties:

   com.muwire.core.collections.CollectionManager.level=FINE

2. Start MuWire, and click on the Collections tab. Wait until all shared files load; you should see the following the logs:

   [timestamp] INFO com.muwire.core.collections.CollectionManager load loading collections
   [timestamp] FINE com.muwire.core.collections.CollectionManager$_load_closure5 doCall processing [path to .mwcollection file]
   [repeat for each .mwcollection file]

If you see these two lines but the collection is still not visible in the UI, then there is some UI problem. If the lines are missing, then there is a problem with the loading of collections. If there are any entries at WARNING level then something is wrong also with loading of collections.

If the lines do not appear until another user requests the collections, then something in the startup sequence isn't correct and we'll need to investigate with more logging.

[Searinox]

Okay, so.

There are two things to note here:

1. I enabled logging as you asked. I then loaded the application and saw the two lines you quoted as the application opened. I then tried to get the collections list and to my surprise the collection list was actually NOT retrieved this time, that is, the retrieval showed that the node had no collections. I then went into the logs and saw this at a timestamp matching when I made my attempt:

FINE com.muwire.core.collections.CollectionManager$_load_closure5 doCall not all files were shared from collection C:\Users{USER}\AppData\Roaming\MuWire\collections\local{ID}.mwcollection, deleting

Something clicked at that point. The content I am SHOULD have all been static but there is one exception: I am actually running the MuWire ZIP instance you gave me from within one of the shared folders, and although the profiles are not present there I imagine a modification in one of the local files such as MuWire.log may well have been enough to mark a file as no longer being present, or one or more files being inaccessible because MuWire was keeping them busy.

Even so, I find it a poor behavior that if one or more files in a shared collection are - for whatever reason - inaccessible or modified, the whole collection should be deleted from MuWire. This is likely what happened here and the entire MuWire collection - a big collection - was deleted because a handful of files were no longer accessible. These files should be removed/updated from the collection itself instead of the entire collection being deleted.

2.

With knowledge of what was going on, I went ahead and repeated the test, this time without running MuWire from a folder currently being shared.

According to the log, the collection was loaded successfully with both log entries you listed being present. This happened shortly after all the shared files were fully loaded, which takes a while. After this completed, the Collection was indeed correctly loaded in the interface!

This leads me to the conclusion that Collections are not listed until all shared files are loaded. However, because this takes some time on my end, and because the interface doesn't specify it, I was under the impression that the collection is never listed. Also collections appear to be quite sensitive to file changes, so much so that if one file is no longer accessible the entire collection is removed. Thus:

-I think the collections list should be disabled from modifying if there are any share/unshare tasks running, with a text label explicitly mentioning that there are ongoing share/unshare tasks running and the list is not editable until they are complete.

-I think a Collection should continue to be available, and update itself when its files are modified/deleted. This means each Collection keeping a list of of the original root folders that were shared and then going through them recursively to see what was added or deleted. In the event that this is too complicated, since MuWire can already detect when files are missing, it should mark the Collection in some way so that on the UI it shows up that some files originally published are now missing.

[zlatinb]

Ok, so the two action points for me are:

1. While files are loading display a message on the Collections tab that basically says "collections will be loaded after all shared files load"
2. Mark the collection as inconsistent if a shared file is no longer available instead of deleting the collection. Collections are immutable, can't be edited after creation. I can color the collection gray or display a warning icon or something like that and not return it in search results; this way the user can rebuild the collection at their convenience.

[Searinox]

1. Sounds about right yes; if Collections are temporarily unavailable, the user should know that and know when to be working again.
2. The immutability of Collections was not known to me until you explicitly pointed it out just now so certainly messages pointing out missing files/warnings would help in explaining to users that once a Collection is made, it is not meant to be changed.