Inconsistent handling of SMB paths

[davydm@…]

This isn't a new bug, really -- the behaviour has been there for some time. But since I've managed to get muCommander to be used whenever I want to browse my filesystem (using a little launcher called Executor), I've gotten really used to just typing in a path and getting muCommander up and running with the path. I see that muCommander can accept two commandline arguments, and load both panes accordingly -- very useful.

However, when passing network shares on the commandline, I have varying levels of success. Here's a breakdown:

muCommander.exe \\server\share

-> muCommander loads with the server's share present in the left pane. Expected behaviour

muCommander.exe \\server

-> muCommander loads with my c:\ drive in the left pane, as if the request wasn't understood

muCommander.exe smb://server/share

-> as above: I get c:\ in the left pane

muCommander.exe smb://server

-> as above: I get c:\ in the left pane

Now, from within muCommander itself, typing the resource path into the path bar:
# \\server
-> "The folder doesn't exist or is not available"
# \\server\share
-> browses to the share on the server (expected behaviour)
# smb://server
-> enumerates all shares on the server (expected and _appreciated_ behaviour!)
# smb://server/share
-> enumerates the contents of the share on the server (expected behaviour)

I've also noticed that muCommander seems to incorrectly remember my login credentials, even when I check "Store login and password (weak encryption)". This used to work, btw. Here's what happens:
# smb://server/share
-> login prompt; I input my network user name and password and select "Store login..."; I press enter, and I'm presented with the files in that share; now, repeat exactly the same:
# smb://server/share
-> login prompt; my name and password are filled in; however, when I press enter (or select OK), the login fails. Re-entering my password works. This can be repeated ad infinitum.

[davydm@…]

I downloaded the nightly today and things have worsened ):

I still can't browse to a machine by \\<machine name>
I can still browse to a share by \\<machine name>\<share>
I can't seem to browse ANYTHING via smb://<machine name>/<share>
I no longer get a list of all shares on a remote host when trying to browse smb://<machine name>
Instead, I now get the cryptic error:
Unable to read folder content: Connection in error

Please assist. The drive selector is MUCH faster now, so I want to use a recent build; crippling the windows shares functionality is a downer in the face of improvement ): I'm escalating the severity too, since this build has an introduced regression (smb:// links don't seem to work at all)

[maxence@…]

Hi Davyd,
Sorry for the slow turnaround. I have just updated the SMB filesystem with the latest version of the jCIFS library (1.3.8), which fixes a number of connection issues. Domain-based authentication is also now supported.

Would you mind giving the latest nightly build a try and report if connections are now successful ?

Thanks!
Maxence

[davydm@…]

No worries. I will probably only be able to check this out later this week since I'm not at work for most of the time -- and that's the only place where I really use SMB.

Will report back when I have an update.

[davydm@…]

Hi Maxence

I've given the nightly build a bash this morning. The handling of different URI schemes for SMB is still inconsistent:

1) typing \\server\share into the url bar takes me to a share which I have auth for on the network without prompt (correct behaviour)
2) typing smb://server/share into the url bar gives a username/passwd prompt (I shouldn't have to since I'm auth'd by domain for this share, but still). After typing in my username and password, however, I'm denied access to the share.
3) via neither \\server nor smb://server can I get a listing of shares as I used to under much older versions of muCommander -- this is a real loss since I used to use this feature a lot, especially since muCommander enumerated "hidden" and "admin" shares alongside the public ones.

[maxence]

Hi Davyd,

Sorry for leaving you once again in the dark. Here's an update on the SMB situation:

• the jCIFS library has been updated twice since my last comment, now at version 1.3.12. A number of bugs have been squashed in recent jCIFS updates, which may or may not improve the situation.
• an issue causing credentials not to be stored has been fixed (see #173).

Among the various issues you describe, I'm particularly worried about the connection failures (2/ and 3/). There have been other recent reports of SMB connection issues (#232 and #146), which also seem to indicate regressions over 0.8.3.

I'm trying to figure out what may be causing those issues but it's hard for me as I'm unable to reproduce them: I'm having no problem at all connecting to Windows XP and OS X (Samba) shares. So your help is all the more appreciated :)

Here are a few more things to try if you don't mind:

a) Grab the latest nightly build a try and see if things have improved.
b) I'm attaching a custom build where I have disabled several tweaks that I made not too long ago (after 0.8.3) and which I'm suspecting for causing trouble.
c) You can try adjusting NTLM configuration variables, as described in #146.
d) You can also try and set the domain in the 'Connect to Server' dialog to see if that helps authentication.

Thanks a lot!
Maxence

[maxence]

Custom build with certain SMB properties tweaked: DFS referral and timeout are left to their default values.

[daf]

Ok, well here's an update (thanks for taking a look at the problem)

Nightly build: behaviour is unchanged
mucommander_smb_defaults.jar:

\\server -> "this folder doesn't exist or is not available"
\\server\share -> works without prompt (as expected)
smb://server -> works as expected (listing all shares, incl $ shares),

_after_ prompting for user/pass (must include domain)
changing smb node in preferences.xml didn't change behavior here

smb://server/share -> works, after prompting for credentials

In the last case, the creds dialog had remembered my last values (even with the "store login" checkbox unchecked, and the same creds worked. Now, I could kinda deal with 1 login, but after I've gone to smb://server with some creds, could muCommander not just try again with the same creds? Chances are quite good that the creds havn't changed). Of course, the ultimate fix would be to use NTLM quietly, with no creds dialog popping up

so, with the build you linked here, we have working statuses:
#1 - 0%
#2 - 100%
#3 - 50% (would like to see the creds prompt die)
#4 - 50% (as above)

[maxence]

Thanks for the quick reply!

So we've narrowed the cause of those connection issues, I'm glad! In the previously attached build, I had changed 3 connection properties: one controlling the DFS referral and the other two controlling timeout values. I'm attaching another build where only the DFS referral property is changed.
Could you please confirm that the behavior is the same as the previous one (=improved)?

Now, regarding the authentication dialog popping up systematically, I agree with you, it's annoying. The reason you can't bypass it is that it's the only chance you got to enter a different set of credentials. I have just created a new enhancement ticket describing a potential solution: #267. Feel free to add your comments to it.

Thanks again!

[maxence]

Custom build with SMB DFS referral left to its default value.

[maxence]

Hi again,

I think I have found the real cause of those SMB issues: Proguard code obfuscation/shrinking. I usually run custom-made, non-obfuscated builds of muCommander and all is well for me SMB-wise. Then today, I downloaded the current nightly build and could not connect to a usual SMB share of mine. The same build without obfuscation would connect to the share without problem.

I have upgraded Proguard to the latest version (4.4) and the problem seems to be gone: I no longer have any problem connecting to this share with an obfuscated build.

Note that the mucommander_smb_defaults.jar build I had attached was not obfuscated, which would explain why connections were no longer failing, rather than the connection properties I changed.

Could you please download the current nightly and let me know if the connection problems are gone, i.e. as they were in your last comment?

[daf]

Ok, so here's the latest functionality matrix, is it were (:

smb://server -> works after creds prompt
smb://server/share -> works after creds prompt
\\server -> doesn't work (folder doesn't exist)
\\server\share -> works after creds prompt

So the update in the obfuscator seems to have worked. But I have to make the query (perhaps I'm just missing something...): If muCommander is an open-source program, and I can browse, download and build from the source myself, then what is the point in obfuscating the code in releases? I mean, I kinda get it for the case where people think that security through obscurity will save their code from prying eyes (which it doesn't really, if the eyes in question are attached to an individual of sufficient determination), but I *really* don't get it for an opensource project? All it means is that if one of your users finds a problem and manages to code a fix or a workaround, they would have had to download a source release and work from there. Is there some other benefit to be gained from the obfuscator? I'll be totally open here and put out there that I'm NOT a java dev, so I don't know if there is some other benefit to be gained (speed? (I would expect not) size? (perhaps)).

As a dev (non-java), if one of the tools I'm using causes a problem, I start to query the use of that tool (ie, can I do without the tool altogether?). But that's just me (:

[maxence]

Hey Davyd,
Thanks a lot for the confirmation. I'm glad we finally nailed the connection issues! I'm leaving the ticket open though, as the original issue (inconsistent handling) remains unchanged.

Your question about the pertinence of obfuscating the code is a perfectly valid one, and here's my take on it. But I have to clarify something first: when I said 'obfuscation', I took a bit of a shortcut. Proguard actually does three different things:

- code obfuscation: renames classes, methods and fields by shorter names, (e.g. com.mucommander.Launcher#main would become something like i#k), making the code more difficult to read when decompiled. A side-effect is that the Java bytecode becomes smaller and thus faster to execute, and with a smaller memory footprint.
As you said, we have nothing to gain from obscuring the code. What's more, we don't want to do it because all Java stack traces would become meaningless and render any attempt to understand the stack trace pretty much useless. So even if there is a speed/memory gain, we don't want to obfuscate the code and it's currently disabled in all builds.

- code optimization: tries to optimize the bytecode, to make it a bit leaner and faster to execute. I'm not too familiar with what this feature actually does but for all I know, the last time we used it it broke our builds so we left it disabled.

- code shrinking: removes bits of code (methods, classes) that are never used. This feature is very interesting for us, as there is a lot of functionality in the libraries bundled with muCommander that we don't use.
Code shrinking has a substantial effect on the JAR file size, which goes from 4.7 MB to 3.2 MB. It is currently enabled in all builds.

To be perfectly honest, when I discovered the SMB issues were caused by Proguard, my first reaction was to drop Proguard altogether. But then I figured saving 1.5 MB on the JAR file was probably worth a fight or two :) though I agree it's debatable.
For now, I'll keep Proguard in mind when bumping into weird/unreproducible errors, and will think twice before upgrading to a new version. And if we run into other issues, yes, we'll definitely consider dropping it.