Some Download tasks disappear after the Hash List is downloaded

[Searinox]

Some Download tasks will simply vanish after the Hash List is obtained. This happens even if the download is set to retry indefinitely. Though it appears that the download task is now gone, it will reappear when MuWire is restarted. When it does reappear, the download may very well proceed correctly if the source is still available.

The circumstances under which a download will behave this way tentatively appear to be tied to whether or not that file is already being shared by the MuWire instance performing the download. This occurs regardless of whether or not the "exclude local files from results" option is checked.

[zlatinb]

I'm not sure what the right way to handle this situation is - namely when the user is downloading a file they already have shared.
a) let them proceed with the download a new b) just copy the file over to the downloads directory and pretend it has completed c) something else? warn them somehow?

[Searinox]

I have been thinking of scenarios where it can make sense to download files that are already local.

One example has been downloading a big package of files that by and large is new but may contain one or two files that already exist locally. An example I can think of is a software suite where one or more folders that contain the same desktop.ini file(assuming "share hidden folders" is checked) or empty files called ".LOCK" which is a common practice in some applications.

I believe it makes sense to save the network unnecessary activity by making the Download task simply provide a copy of the local file, provided that the Download task explicitly mentions that it is doing this so there isn't confusion for the user.

Either way something must happen because whether the file ends up being copied from local share or downloaded entirely, the current behavior as it is is buggy: the task dies suddenly, appears to no longer exist, then pops back. For starters I can imagine this being a privacy issue:

MuWire is running on an anonimity network and users very much like - and expect - options to cover their tracks, and already MuWire provides an option to not save search history(on this note, there should probably also be an option to never save open search tabs on restart). If a person has tried to downloaded a file they don't want others to potentially see, and they think the download task is gone, only for it to appear out of nowhere again on next application start, it can be an issue.

Second, you also cannot cancel such a task once it gets stuck in limbo without restarting the application, which is annoying.

[Searinox]

If you do go with option [B] - copy the file from the local share - remember to keep the filename capitalization the same as it was in the download rather than its local name.

[Searinox]

I think there should also be a distinction between files found on OTHER SOURCES that are already shared by you and files from YOURSELF. Once I unchecked "exclude local files from search results", I could also find MY OWN files in the search results. I don't see a reason for MuWire to ever ping itself to get its own search results, even when the shared files are common.

Attempting to then download one of my own shared files from myself results in an immediately "Finished" download that is then delisted even though nothing is downloaded anywhere.

MuWire should always exclude its own node from searches and download attempts. If I wanted to search and find files in my own share, the filter in the Library tab can do this without looping it back through the network.

I can understand if from some manner of traffic analysis anonimity perspective it is sensible to ping EVERY node with a search, including yourself. But then your own results should be excluded from the search results UI.

[zlatinb]

I think option B) makes most sense - of course the file name will be taken from the search result, not from the local file. The UI will also clearly say that it is "copying local file" or something to that effect.

Regarding searching from yourself, the results do not go over the network, they go over loopback inside the muwire process. The library filter functionality was added much later, but now that it's there I'll think about disabling loopback results completely.

I'll add an option to not save search tabs across restarts, that is easy to do.

[Searinox]

I was able to encounter a new problem now:

In my attempts to download files from my other node that I also happen to be sharing, I somehow wound up with a download whose status is listed with status "Hopeless". Since the Downloads tab doesn't list source(s) I cannot know exactly where it tried to get it from - I maybe might very well have tried to download to and from the same machine but I'm not sure.

There is no Cancel for the download, the button is grayed out. There is however the Clear Done button. If I click it, the download is removed from the listing but when I restart MuWire it pops back up, again as Hopeless. The result is that I cannot fully remove it in any way from the Downloads anymore. I have tried re-downloading it, but nothing happens.

This shouldn't be happening because I have my instance set to re-attempt download indefinitely. There is also at least one host online to download it from - my other one.

[Searinox]

Small behavior update: I have attempted to Clear Done, then, while the file download is cleared from the list, to download again and cancel while the list appears clean. I was able to start a new download of the file and then cancel it. Upon restarting MuWire, the old Hopeless download was back again. Still no way to get rid of it.

[zlatinb]

Thanks for the report, it's probably related to the fact that the downloading node was also sharing the file. "Hopeless" means that all sources have been tried N times, but I think in this specific case the code got confused because the file was present. Either way, as I fix the behavior to copy locally shared files I'll take care of this too.

If you need to get rid of the download manually, stop MuWire, look in c:\Users\<username>\AppData\Roaming\MuWire\downloads.json for an entry with matching size and delete that line, then restart MuWire.

[Searinox]

I am clearing it now. Before I do so, I am posting here what the contents of the file were, in case it is of any help for you to see what kind of state the file got stuck in. Both the download size and power-of-two value have been altered for anonymity purposes. And of course, the IDs. But everything else is unaltered:

{"file":"{VALUE1}","length":123456,"pieceSizePow2":5,"destinations":[],"hashRoot":"{VALUE2}","paused":false,"sequential":false,"incompletes":"{VALUE3}"}

[zlatinb]

Hi, in the referenced commit above I implemented copying of local files instead of trying to re-download them. Please try following build https://muwire.com/downloads/MuWire-0.8.9-GitHub68.zip and let me know if I can close the issue.

[Searinox]

This appears to have worked. On my tests it did "Copying" instead of "Downloading" and appears to have completed well. You can still find your own files in the search results though, even when you're their only source.

[zlatinb]

Thanks for testing.

I'm not very sure if I should disable finding own files in search - it's very useful when developing and also when you want to see how your files appear in results to others. I plan to add "Tree View" for results in the next version and then people will want to be able to see how their tree looks like. Anyway, we can discuss in a separate issue, I'll close this one now.