D8387: Workaround incorrectly returned EEXIST instead of EPERM regression introduced by libsmbclient 4.7

[Michal Malý]

madcatx added a comment.


  In https://phabricator.kde.org/D8387#157502, @ngraham wrote:
  
  > So am I correct that this patch does the following:
  >
  > - If you go to a real password-protected samba server, without this patch you are totally screwed; with it, you are correctly offered a chance to enter your credentials
  > - If you go to an invalid address that doesn't exist, without this patch you are told that; with it, you are erroneously offered a credentials window, making you think that the address is real
  >
  >   If so, is there any other way to check whether the server address is valid besides getting back EEXIST?
  
  
  This is pretty much the case. One way how to get the login dialog without the patch is to manually enter a valid path like this: "smb://SERVER/valid_share/valid_directory". In this case libsmbclient returns EPERM instead of EEXIST if the requested directory is password-protected. I believe I descried this in a bit more detail in the Samba bug report.
  
  In https://phabricator.kde.org/D8387#157551, @graesslin wrote:
  
  > Could you check which libsmbclient version is used and ifdef the change?
  
  
  Ifdefing around this won't do much good because applications should not require a rebuild against updated libsmbclient. Peeking through the header file I discovered `const char * smbc_version(void)`. I'll see if I can use this to restrict this hack only to the troublesome libsmbclient versions. Stay tuned.

REPOSITORY
  R320 KIO Extras

REVISION DETAIL
  https://phabricator.kde.org/D8387

To: madcatx, ngraham, davidedmundson, elvisangelaccio, #frameworks
Cc: graesslin, z3ntu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20171021/89a40d45/attachment.html>