| ngraham |
same as the ftp does. in fact, also steal the error message qtcpsocket
produces. effectively this makes smb://unavailableipaddress spit out
exactly the same error as ftp://unavailableipaddress
host unreachable being so vague, the pretty string continues to be vague
as well unfortunately.
BUG: 417166
FIXED-IN: 20.08.0
error upon accessing the unassigned address 192.168.1.99 is same between smb and ftp
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
I tested out this patch by unplugging the network cable to the machine hosting my samba share and then trying to connect to it in Dolphin using the saved location in my Places panel where I access it from (smb://gaston@living-room-pc/Users/gaston/Desktop/) , but I still see the same error message as before:
Interestingly enough, if I connect to just the server (smb://gaston@living-room-pc/), I see a different error message:
However I never see the new message. What am I doing wrong?
Use an ip address that isn't used by anything. Failing to resolve the hostname is different from failing to contact an ip address i.e. "I dunno who this is" versus "you have called a number that has been disconnected or is no longer in service".
So like this?
Hmm, I'm not really sure. For one "timeout on server" is pretty jargonistic. Also, in this case, there is no server! I think the "Could not connect to host for <blabla>" message is more user-friendly for this case. It also better matches what's suggested by the ERR_CANNOT_CONNECT name.
Nah. 50.50.50.50 is an actual host on the internet for all your router knows ^^
You need to use an unassigned address within your actual home network, otherwise your router will (likely) send it off to the internet and then it will bounce around there for a bit as every router goes "does any router know 50.50.50.50?" until smb is tired of waiting and times out. Which is precisely what happend to you, IOW "we tried to talk to this host but got no reply before we got sick of waiting" and the waiting happend because routers all over the world tried to figure out who 50.50.50.50 is.
The actual error this diff introduces is for example:
Somewhat unrelated, but, if you check job_error.cpp in KIO you'll find KIO::Job::detailedErrorStrings which is backed by KIO::rawErrorDetail and that has mountains of causes and possible solutions for a lot of the KIO error types. Dolphin should really find a way to use that data somehow and the data should be polished I guess, it's probably been dormant since kde3. I can totally see why a single line description for an error is not accurately explaining what that error is, what it means or what to do about it.