Search result display shows helpful information.

I am finding the search results are somewhat more inclusive now or perhaps it's just the search terms. Keeping the searches simple appears to bring in more search results.

I'm starting to wonder if there is a problem at my end because I appear to have skipped 0.5.9; I am yet to see an update message.

After the update I noticed search hits and upload counts reset. Thus instead of overall I guess it's now a per session which is more appropriate.

I noticed Advanced Sharing - Watched Directories with 0.5.8, something I had not noticed previously. I apparently have ten directories watched for file changes.

Negative Tree (Files which are explicitly not shared): I notice there's directories listed that I'm also supposedly sharing. At least two of them only have one kind of file so there was no reason not to share anything from those folders and makes me wonder why they should be listed in the negative tree.

If certificates have been produced and you wish to adjust the name of the file, how difficult is it to make changes without polluting (creating a mismatch with) the certificate or removing and replacing the certificate? AFAIK changing the file name (not id tag name) of a file should not change the hash of a file, but the certificate is a different kettle of fish.

Unless you changed the default update check interval from every 24 hours you would have missed 0.5.9 because it lasted less than that lol.

I had to change the format of the search hits to show who has performed the search, that's why they reset. They are still persisted across sessions. The upload counters should not have reset though.


The negative tree lists files which are not shared but are inside a watched directory. If you see a directory there it just means the directory is shared, only if you see a file inside such a directory it means that specific file has been explicitly unshared. The negative tree display is more for debugging purposes as you can't really do anything with the tree, it's read-only.

It's impossible; the point of certificates is that they are a snapshot of the file at a specific time. If you want, you can delete the certificate file from the ~/Library/Application Support/MuWire/filecert directory but as the warning says someone may have already gotten it from you. There is no problem issuing a second certificate though, just click "Certify" again.

No wonder. Mine's set to 48 hrs but I don't recall manually changing it.
Will the certificate upload show in the upload window? If yes I'm safe on this occasion.

The certificates folder is a little confusing when you have many. Since I certified all simultaneously there was no time/date indicator either to give a hint. I was not enthusiastic about opening up over 1k of certificates to find several dozen. So I started them from scratch. Unless a file has been changed I presume the certificate would be identical to the original in any case (with exception of date and time listed within.)

No, certificates are shared via a completely different code path and it will be difficult to display how many times a certificate has been uploaded anywhere in the UI. Also, just because it's been uploaded doesn't mean the remote side has imported it (the user has to click "Import" in order to store someone else's certificate).



Indeed, managing certificates manually is not easy and I don't really want it to be. This is a feature users should be careful with, hence the warnings in the UI and on the wiki. If you have deleted any certificates manually, you should restart MW because it caches them in memory.

I did. Also there'd been no uploads since adding the original certificates so no issue this time.

Any possibility of also adding a Find (or Locate) on Disk tool to library & uploads?

You've been doing a great job with this project.