Some users get "file not shared" only when downloading containing folders

[sunox1]

Hello,

I've been having a frequent issue where I see a string of Queued upload request: User [user]... messages (one for each file a peer is attempting to download from me), but no files are added to my Uploads. I usually try to message them to see what's happening on their end, and every person who has responded has said that they received a File not shared error.

Curiously, one user who got the error said that they could download the same file that just failed by clicking on each song individually; they only got the error when selecting Download containing folder(s). Consistent with this account, I haven't seen this queued upload request problem happen with any single file downloaders.which happens pretty frequently. I looked to see if any of the problematic folders had any weird characters, and they looked normal to me.

According to some research I did, the File not shared error is caused either by the client not having the proper permissions, or because of a port forwarding issue. All my files and folders have 755 permissions, so I don't think it's that. A user in chat thought it might be ports issue, where either myself or the peer couldn't receive direct connections. They thought it was just something that happens with soulseek. They suggested I try to telnet the ports of the peers who had a failed download to see if they are open or not, but I can't seem to connect to any external ports with telnet - not sure why. This person could telnet to my ports, which seems to confirm its not a ports issue on my end.

This happens around once for every five users that try to download from me. I do not see anything like this happening with QT, which you might expect if it was just a soulseek thing like the person I talked to suggested.

It's not a gigantic issue for me because I am getting a lot of uploads lately, but I just thought I should mention it. If I'm the only person with this issue, I'm more than happy to just live with it.

I should perhaps note that the file system my songs are located on is NTFS. I don't have any issues with this setup otherwise, but maybe it's a potential problem. Edit: I actually think I'll try reformatting this drive as ext4 sometime tomorrow, just in case. Edit2: Problem still exists after formatting to ext4. ¯_(ツ)_/¯

Thanks!

[sunox1]

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).

[sunox1]

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 :/

[ghost]

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.

[sunox1]

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.