Some users get "file not shared" only when downloading containing folders about nicotine-plus HOT 4 CLOSED

So I just encountered the problem, and I messaged the user that it should work if they download each song individually. They did so, and it worked - they were able to download everything fine.

Here is a screenshot of the log: https://imgur.com/ZFVwILn. The failed attempt is the first series of Queued upload request messages at 20:50:15. The later, successful attempt is directly below.

There are two abnormal things about the log output that I can see. 1) in the failed attempt, the filename strings are all lowercase, and they are properly capitalized on my pc - they look like the filenames in the successful attempt messages; 2) for the successful transfers, there are two messages for each queued upload request. Edit: I see the two-messages thing happen fairly frequently, so I'm not sure if it is relevant to this problem.

Now that I have a second example of the individual-download solution, I think we can say with relative confidence that the issue targets specific users (rather than specific files/directories), and that it is caused by Download containing folder(s).

from nicotine-plus.

So after switching too ext4 and then rebuilding public shares (this way key), the number of instances of the problem dropped dramatically. I even noticed a number of DLs pop up from users who were getting the error before - I take it the downloads were sitting in their queue the whole time. I've encountered the problem twice since the switch, but that might be for unrelated reasons. In any case, it really looks like sharing files that were mounted NTFS was the culprit. Maybe it had something to do with how I mounted it... not sure :/

from nicotine-plus.

Hi @sunox1

Sorry I was out last day and had no time to response but that was my first thought too.
I think this is due to how n+ handle filename encoding.
It uses classic utf-8 strings for files on linux filesystems and unicode on windows for ntfs.
The actual if else in the code switch from one mode to the other based on the current running OS instead of being based on the underlying filesystem.
I'll have a look at how to fix this edge case but I think one universal mode for everyione (unicode ?) would solved it.

from nicotine-plus.

No worries! Thanks for getting back. I'm not using Windows on that pc anymore so it was about time I switched to ext4 anyway.

That's good to know! I'm not sure how much effort it would take to change it up, but it would be handy for anyone dual-booting Windows and Linux.

And your mention of a "universal mode" made me wonder if doing such a thing would fix the remaining few instances of this issue I'm having. It's probably closer to 1 in 10 downloads that are affected now, so not a major issue at all, but still maybe an issue (it could also just a general soulseek issue, or an issue with the connectability of the problematic downloaders). I spoke to one user today who had this issue and he got a different error message - simply "Fail" - so maybe it has a different cause? Anyway, I'll leave it alone for now.

Thanks again.

from nicotine-plus.