Custom Query (292 matches)

I didn't have a better subject, sorry. Suggest that this may become a meta bug for all issues with case sensitivity.

Current issue:

Samba server 4.1.8 on openSuSE, configured for SMB2 and no case sensitivity setting for the share in smb.conf should default to auto (see ​https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#NAMEMANGLING). Apparently, while ​https://www.samba.org/samba/docs/man/manpages/smbclient.1.html indicates that the case_sensitive flag should be toggled off by default, we seem to have it on, as accessing a share on the above with:

 7-04-15  17:32         <DIR>    1,252  Desktop
 7-04-15  17:49         <DIR>      548  Images
 7-04-15  17:49         <DIR>        0  RecycleBin
 7-04-15  17:31           1,111      0  POPUPLOG.2014-12-04
 7-04-15  17:31         159,305      0  POPUPLOG.OS2
         160,416 bytes in 2 files and 3 dirs
         164,864 bytes allocated
 465,719,918,592 bytes (433GB) free

running the following command fails:

[c:\]dir k:\images

 Volume in drive K is NETDRIVE
SYS0002: The system cannot find the file specified. "K:\images\*"
               0 bytes in 0 files and 0 dirs
 465,720,012,800 bytes (433GB) free

while:

[c:\]dir k:\Images

succeeds.

It is necessary to actually set the share to case senstivity = no in order for the case-insensitive filenames to be recognized.

This only appears to be an issue with the plugin. smbclient works as expected:

smb: \> ls images
  Images                              D        0  Sat Jul  4 17:49:16 2015

                712503296 blocks of size 1024. 454804620 blocks available

Perhaps a toggle in the plugin properties to enable/disable case-sensitivity for the share would be helpful.

The default setting of SYSTEM as it was before before #236 enables client systems running a different codepage than IBM-850 to work properly, while after #236 the display of national characters fails on these systems.
Patching recent ndpsmb.dll (beta1 refresh or beta2) from IBM-850 to IBM-866 makes the problem go away, which verifies this theory.
The problem is that server and client require either a different code here, or alternatively the codepage must be configurable on the client, either by its own smb.conf or by a control within the GUI.

Adding another share to smb.conf by using a prepared share section in a separate text file using copy /B smb.conf+addx.conf smb.conf makes smbd.exe crash as soon as the next operation rereads smbd.conf.

Note: Changing smbd.conf while smbd.exe is running is a normal operation for external scripts such as addshare and others.