All samba client connections are case-insensitive by default, and the default has to be overridden at a higher level in order to turn on case-sensitivity. smbclient provides a command to toggle case sensitivity, but libsmbclient does not expose cli_set_case_sensitive() as part of its API. I'm not sure it should need to - libsmbclient is intended to be POSIX-like, and POSIX is case-sensitive; I think this should be the default behavior for libsmbclient. The following patch does this. If you don't agree with this solution, then I can provide a patch instead to add a new flag to the context; but I can't see any reason that the default behavior should be case-insensitive in a Unix client.
Created attachment 3876 [details] patch to make libsmbclient negotiate case sensitivity
The only reason not to make it case sensitive by default is that it would break backward compatibility. That's a pretty good reason, though, so let's add an option for it. Note that this no longer means adding flags in the context. No new visible flags are ever added there any longer. All new options are hidden, with getter/setter functions for retrieving and modifying them. Derrell
I would argue that case-insensitivity is not at all a reasonable default, being instead an outright bug, and therefore there's no reason to maintain compatibility with it. What is the use case for a consumer of libsmbclient relying on case-insensitive filename matching on a server with underlying support for case sensitivity?
(In reply to comment #2) > The only reason not to make it case sensitive by default is that it would break > backward compatibility. That's a pretty good reason, though, so let's add an > option for it. Note that this no longer means adding flags in the context. No > new visible flags are ever added there any longer. All new options are hidden, > with getter/setter functions for retrieving and modifying them. > > Derrell > Derrell, it seems that backward compatibility means maintaining the real possibility of data loss since file clobbering happens with no warning at the moment. Is this behaviour worth keeping?
> Derrell, > it seems that backward compatibility means maintaining the real possibility of > data loss since file clobbering happens with no warning at the moment. Is this > behaviour worth keeping? Tim, your point is valid. The flip side is that applications may be assuming, particularly if talking to older servers, that they can open, for example, "config.sys" and get "CONFIG.SYS". That's the backwards compatibility I'm concerned with. I think, though, that the potential for data loss you reference overrides that, and those older servers are being fewer and fewer by the minute. I'll make the change of default, but provide an option to revert to the former behavior. Derrell
Fixed in all branches. Thanks!
I took another look at this. The determination of whether to use case sensitivity should really, I think, be based on whether the share to which we connected supports case sensitivity. I've added this feature now, and the user option for case sensitivity is only used if for some reason we can't determine the case sensitivity of the file system. Committed to all branches. My test environment is limited, so additional testing would be appreciated. Derrell
Derrell, I understand that this patch is the conservative approach in terms of assumptions about the server, but out of interest, what happens if a client requests case-sensitivity when talking to a server that *doesn't* set the FILE_CASE_SENSITIVE_SEARCH attribute? Do such servers not provide a sensible fallback behavior?
> Derrell, > > I understand that this patch is the conservative approach in terms of > assumptions about the server, but out of interest, what happens if a client > requests case-sensitivity when talking to a server that *doesn't* set the > FILE_CASE_SENSITIVE_SEARCH attribute? Do such servers not provide a sensible > fallback behavior? I would think so, but I don't have any such servers available to test with. If I'm understanding the intent of your query, you're asking whether we should even allow the user to set anything at all, for those cases where the server doesn't provide the information to us? We could just always use the case-insensitive setting if the server doesn't tell us what to do and eliminate the user option entirely. I'm not wedded to having the new option available, although I do prefer to err on the side of letting the user choose rather than making an educated but otherwise somewhat arbitrary decision on my own. Or am I entirely misunderstanding your query? Derrell
Derrell, for testing, the Debian bug report shows how the bug can be reproduced using a Linux samba server and a Linux client running gnome. I mention this in case it helps. When a new package arrives in Debian I will of course test it as an interested user. Steve, the Debian Developer looking after the package, considers it fixed. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511744