Run Flood and torrent client on different platforms

[xkillermaverick]

Type: Bug Report

Your Environment

• Version used:
  • Version (stable release) : 4.4.1 (with NPM)
  • Commit ID (development release) git --no-pager log -1 :
• Environment name and version:
  • Node.js version `node --version : v15.8.0
  • npm version `npm --version : v7.5.3
  • Operating system and version: Fedora 33 (Server Edition) Kernel 5.10.13-200.fc33.x86_64
• Torrent client and version: qBittorrent v4.3.3
  • Operating system and version: Windows 10 Version 20H2 Build 19042.804
• Web browser `name and version : Microsoft Edge Version 88.0.705.63

Possible Solution

Remove the path correction code, Improve the path correction to recognize a windows path "A:/", Make path correction code Toggleable by the user.

Steps to Reproduce

1. Install flood on Linux
2. Install Torrent Client on Windows
3. qBittorrent Errors out due to the path looking like /A:/Torrent/Downloads/ when it expects A:/Torrent/Downloads/

[jesec]

This is not a supported case. README very clearly notes that you have to run Flood and torrent client on the same machine.

[xkillermaverick]

ok but everything works this is the only issue,

[jesec]

Flood needs the same filesystem context, which is not achievable when Flood is not on the same platform as torrent client. You may get a minimally working web UI but many features DO break.

[xkillermaverick]

i understand that but none the less why do even need to add / in the path if it does not have one? why not add it before the user adds the torrent. actually can you message what features break in flood?

[jesec]

Because that’s how Unix path works. This is the expected behavior of path expansion function when executed on a Linux machine. It simply can’t go other way. Otherwise, things can break for people who do have a correct setup.

Some features that break:

• Browse folders (filesystem browser)
• Disk usage
• Download contents
• Download .torrent
• Stream contents
• mediainfo
• etc. depends on your torrent client. certain clients have increased reliance on Flood

[afontenot]

I don't see any need to be rude.

"Could not be verified" does not mean the same thing as "cannot connect". In fact the implication of using a circumlocution like "can't be verified" is that you are deliberately not saying that it couldn't connect. In other words, the takeaway for the alert user is "I can connect, but something else went wrong when I tried to ensure the connection will work / remain stable." And then the user is left to guess what that is. The very fact that we are having this conversation is proof that at least one person found the message to be misleading, whether you do or not. (The screenshot you show is not the error I got, by the way.)

Also, it's one thing when you're writing software for your own use, but another thing when you're trying to make something for a general audience (or, as in this case, taking over development of a project for a general audience). "It fails because it fails" would be a bad error message, obviously. If there are obvious foot cannons, you should probably try to avoid those. If there is information you could provide that would enable the user to debug a problem more easily, you should provide it. Not every piece of open source software is for people who make six figs at Google developing targeted advertising. I shouldn't have to read the code or dig through a mountain of documentation to figure out what went wrong when it's as simple as "the permissions on the socket file are too strict".

[jesec]

I apologize. To be honest, it is quite frustrating. I think users should at least have some skills to figure out their own stuffs. README and other documentations already provide more than enough information. If some users think they are advanced enough to use some weird setups, they shall take up the responsibilities and deal with the troubles (instead of complaining about error messages).

Unfortunately, from a security perspective, it is unwise to expose too much details about system internal to the frontend. Generally, when such a connection failure happens, you will see logs and traces on the server side instead. And, with a proper setup, such an error shall never happen.

I don't think there is anything I can do. However, if someone else feels there is such a need, I may as well accept a PR.

[afontenot]

Thanks, and also, I'm sorry for responding a bit dramatically and generally wasting your time.

I agree with you about leaving advanced setups for more knowledgeable users. To be clear, I was able to fix the issue myself very quickly - my complaints about it here have all been with the goal of highlighting what seems to me to be a confusing error message. I think you're likely to see other users confused by it in the future.

For the record, I was able to replicate the error. It looks like this:

You might ask why I ignored the "Cannot connect to the client" message. The reason is that that text was already in the modal (it's the modal's title) before I clicked "Save Settings". I got to this by having a broken configuration after updating from a previous version of Flood. Initially the modal said that it couldn't connect, and then I added the path to the socket, clicked Save, and got the "Connection could not be verified", which popped up in red. So my read of the situation was that the purpose of this modal was to fix my connection, hence the title ("Cannot connect to the client"), and that after entering the path, the popup message in red was the result of attempting to connect. In fact it was probably the contrast between the two messages that led me to believe that "verification" referred to something different. Would a smarter person than me have immediately recognized the intended meaning? Maybe.

Sorry if my story is boring, I just find that in development it's often useful to have user stories which indicate how they interacted with parts of a UI.

Not 100% sure I understand what you mean by a security perspective here, I would've assumed no one except logged in users are ever supposed to see the "cannot connect to the client" modal. Once you do the initial setup, Flood is presumably supposed to be secure against additional users gaining access. So my thinking was that Flood could give the user a message like "Flood does not have write permission to the socket" (or even "EACCES -13 /tmp/rtorrent.sock", which is at least searchable).

[xkillermaverick]

Hey have you check SELinux if flood does not have permission then yes its something on your end

[jesec]

Can someone explain to me how this thread is related to the feature request of "run Flood on Linux and run torrent client on Windows"?

I am hiding this thread since it does not seem to relate to the OP. Things are getting more confusing as time passes.

As for the SELinux, if you think you are advanced to use that, you should deal with troubles. Flood does not have that sort of checks.