smbstatus -L works OK for Windows XP clients when listing locks, but for pre-W2K clients (observed on NT4 and Windows ME), some (apparently not all) of the pathnames are unreadable. The pathname appears to be translated into random non-printing characters (invalid unicode conversion?). Capture script and sample output included below. George Cameron #!/bin/sh smbstatus |\ egrep '[^a-zA-Z0-9 :_~\.\/\$\&\#\(\)\n\+\-]' \ > capture.dat 11394 DENY_WRITE 0x1 RDONLY NONE R< Mon Oct 13 16:44:29 2003 10138 DENY_WRITE 0x1 RDONLY NONE R< Mon Oct 13 15:55:10 2003 1256 DENY_WRITE 0x1 RDONLY NONE R< Mon Oct 13 14:39:35 2003 15442 DENY_WRITE 0x1 RDONLY NONE R< Mon Oct 13 14:35:07 2003 1119 DENY_WRITE 0x1 RDONLY NONE R< Mon Oct 13 14:30:19 2003 32285 DENY_WRITE 0x1 RDONLY NONE R< Mon Oct 13 13:40:42 2003 6349 DENY_WRITE 0x1 RDONLY NONE R< Mon Oct 13 12:49:17 2003 2713 DENY_WRITE 0x100020 RDONLY NONE R< Mon Oct 13 09:47:54 2003 2381 DENY_WRITE 0x1 RDONLY NONE R< Mon Oct 13 09:26:19 2003 32030 DENY_WRITE 0x1 RDONLY NONE R< Mon Oct 13 07:45:13 2003 6349 DENY_NONE 0x1 RDONLY NONE _ Mon Oct 13 14:19:05 2003 1498 DENY_NONE 0x1 RDONLY NONE _ Mon Oct 13 10:27:28 2003 11394 DENY_NONE 0x1 RDONLY NONE } Mon Oct 13 16:44:32 2003 15442 DENY_NONE 0x1 RDONLY NONE } Mon Oct 13 16:30:34 2003 10138 DENY_NONE 0x1 RDONLY NONE } Mon Oct 13 15:55:24 2003 1256 DENY_NONE 0x1 RDONLY NONE } Mon Oct 13 14:39:38 2003 1119 DENY_NONE 0x1 RDONLY NONE } Mon Oct 13 14:30:30 2003 32285 DENY_NONE 0x1 RDONLY NONE } Mon Oct 13 13:40:48 2003 6349 DENY_NONE 0x1 RDONLY NONE } Mon Oct 13 12:49:23 2003
Can you please provide more details about your configuration? It is unclear what settings in smb.conf do you use for character set handling.
no feedback in over a month. Assuming a configuration issue.
reopening so I can marked it as fixed.
1. This problem does in fact appear (on quick testing) to be resolved in 3.0.2a 2. Our smb.conf configuration has had no significant changes (added 2 global parameters, 'host name lookups = no', which I believe is default anyway and 'socket address = 139.133.211.5') 3. Thus my (non-expert) conclusion is that there may have been an actual bug which was resolved as a result of the changes between 3.0.0 and 3.0.2a, rather than a configuration error.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
database cleanup