Re: [cifs-discuss] bug when processing wildcards for file names with unicode

2012-04-11 Thread SSE - Martin Riethmüller

 If you have an 8.3 name that contains non-ascii unicode characters is it
 returned in the directory listing?

 Joyce

Hi Joyce,

I can see these rules:

If the given pattern matches the 8.3 short name everything is working. 
In this case it doesn't matter if the filename contains unicode 
characters or not.
If the given pattern matches behind 8.3 it works when the filename 
does not contain unicode-characters, it does not work with unicode 
characters.


You can see this behaviour in this example:

H:\temp\TEST\8.3dir
 Datenträger in Laufwerk H: ist volumes
 Volumeseriennummer: 75D1-D7F8

 Verzeichnis von H:\temp\TEST\8.3

11.04.2012  14:07 DIR  .
12.12.2011  16:57 DIR  ..
11.04.2012  14:07 0 X_Y-longname.txt
11.04.2012  14:07 0 longname-Ä_Ü.txt
11.04.2012  14:06 0 Ä_Ü-longname.txt
11.04.2012  14:06 0 Ä_Ü.txt
11.04.2012  14:06 0 X_Y.txt
11.04.2012  14:07 0 longname-X_Y.txt
   6 Datei(en),  0 Bytes
   2 Verzeichnis(se), 432.321.776.128 Bytes frei

H:\temp\TEST\8.3
H:\temp\TEST\8.3dir *_*.*
 Datenträger in Laufwerk H: ist volumes
 Volumeseriennummer: 75D1-D7F8

 Verzeichnis von H:\temp\TEST\8.3

11.04.2012  14:07 0 X_Y-longname.txt
11.04.2012  14:06 0 Ä_Ü-longname.txt
11.04.2012  14:06 0 Ä_Ü.txt
11.04.2012  14:06 0 X_Y.txt
11.04.2012  14:07 0 longname-X_Y.txt
   5 Datei(en),  0 Bytes
   0 Verzeichnis(se), 432.321.243.648 Bytes frei

- the Ä_Ü.txt is matching because the _ is found in 8.3
- the longname-X_Y.txt is matching because it does not contain 
unicode-characters

- the longname-Ä_Ü.txt should match but it is missing

Martin

___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] bug when processing wildcards for file names with unicode

2012-04-11 Thread SSE - Martin Riethmüller
 Yes, you can use wireshark on the Windows client. You can also use 
netmon on the Windows client.


O.K., here are the results of network capturing with netmon (Microsoft 
Network Monitor 3.4). Here are the packets from Samba 
3.0.28-0.5-1657-SUSE-CODE10 where everything is working and in an 
separate post (because of the size limit) the packets in Solaris where 
some filenames are missing. In both cases I have expanded the two mosts 
interesting (hopefully!) packets.


What I have done while capturing was the dos-command dir *_*.*

For me the requests of the W7-Client are looking quite identical in both 
cases. It was interesting for me to see that W7 is transferring my 
pattern *_*.* to the pattern *_* . But this is exactly the same in 
both cases.


In the responses of course the solaris answer has only 1 filename, the 
linux box has all matching files. But most of the other informations 
seem to be not very different. Only one thing looks interesting for me:


Solaris is answering with
  IsLongName:(.0..) DO NOT use Long 
File Names (SMB_FLAGS2_IS_LONG_NAME)


but Linux answers at this line with
  IsLongName:(.1..) Use Long File Names 
(SMB_FLAGS2_IS_LONG_NAME)


But because I don't really understand what is happening here I will not 
guess any further...


Martin


SAMBA - LINUX
-
1113:04:39 11.04.20121.0384633System192.168.237.110
192.168.237.213SMBSMB:C; Transact2, Query Path Info, Query File 
Basic Info, Pattern = {SMB:9, SMBOverTCP:8, TCP:7, IPv4:6}
1213:04:39 11.04.20121.0390798System192.168.237.213
192.168.237.110SMBSMB:R; Transact2, Query Path Info, Query File 
Basic Info{SMB:9, SMBOverTCP:8, TCP:7, IPv4:6}
1313:04:39 11.04.20121.0391828System192.168.237.110
192.168.237.213SMBSMB:C; Transact2, Query Path Info, Query File 
Standard Info, Pattern = {SMB:10, SMBOverTCP:8, TCP:7, IPv4:6}
1413:04:39 11.04.20121.0394478System192.168.237.213
192.168.237.110SMBSMB:R; Transact2, Query Path Info, Query File 
Standard Info{SMB:10, SMBOverTCP:8, TCP:7, IPv4:6}
1513:04:39 11.04.20121.0401849System192.168.237.110
192.168.237.213SMBSMB:C; Transact2, Query FS Info, Query FS 
Attribute Info (NT){SMBOverTCP:8, TCP:7, IPv4:6}
1613:04:39 11.04.20121.0404533System192.168.237.213
192.168.237.110SMBSMB:R; Transact2, Query FS Info, Query FS 
Attribute Info (NT), FS = NTFS{SMBOverTCP:8, TCP:7, IPv4:6}
1713:04:39 11.04.20121.0413084System192.168.237.110
192.168.237.213SMBSMB:C; Transact2, Query FS Info, Query FS 
Volume Info (NT){SMBOverTCP:8, TCP:7, IPv4:6}
1813:04:39 11.04.20121.0415697System192.168.237.213
192.168.237.110SMBSMB:R; Transact2, Query FS Info, Query FS 
Volume Info (NT), Label = kunden{SMBOverTCP:8, TCP:7, IPv4:6}
1913:04:39 11.04.20121.0550788System192.168.237.110
192.168.237.213SMBSMB:C; Transact2, Query Path Info, Query File 
Basic Info, Pattern = \TEMP\TEST{SMB:11, SMBOverTCP:8, TCP:7, IPv4:6}
2013:04:39 11.04.20121.0559640System192.168.237.213
192.168.237.110SMBSMB:R; Transact2, Query Path Info, Query File 
Basic Info{SMB:11, SMBOverTCP:8, TCP:7, IPv4:6}
2113:04:39 11.04.20121.0561455System192.168.237.110
192.168.237.213SMBSMB:C; Transact2, Query Path Info, Query File 
Standard Info, Pattern = \TEMP\TEST{SMB:12, SMBOverTCP:8, TCP:7, IPv4:6}
2213:04:39 11.04.20121.0564138System192.168.237.213
192.168.237.110SMBSMB:R; Transact2, Query Path Info, Query File 
Standard Info{SMB:12, SMBOverTCP:8, TCP:7, IPv4:6}
2313:04:39 11.04.20121.0567132System192.168.237.110
192.168.237.213SMBSMB:C; Transact2, Find First2, Full Directory 
Info (NT), Pattern = \TEMP\TEST\*_*{SMB:13, SMBOverTCP:8, TCP:7, 
IPv4:6}
2413:04:39 11.04.20121.0579111System192.168.237.213
192.168.237.110SMBSMB:R; Transact2, Find First2, Full Directory 
Info (NT){SMB:13, SMBOverTCP:8, TCP:7, IPv4:6}
2613:04:39 11.04.20121.0674543System192.168.237.110
192.168.237.213SMBSMB:C; Transact2, Query FS Info, Query Full FS 
Size Info{SMBOverTCP:8, TCP:7, IPv4:6}
2713:04:39 11.04.20121.0699581System192.168.237.213
192.168.237.110SMBSMB:R; Transact2, Query FS Info, Query Full FS 
Size Info{SMBOverTCP:8, TCP:7, IPv4:6}


  Frame: Number = 23, Captured Frame Length = 172, MediaType = ETHERNET
- Ethernet: Etype = Internet IP 
(IPv4),DestinationAddress:[00-0C-29-0F-B5-E8],SourceAddress:[00-01-80-7E-94-A5]

  - DestinationAddress: VMware, Inc. 0FB5E8 [00-0C-29-0F-B5-E8]
 Rsv: (00..)
 UL:  (..0.) Universally Administered Address
 IG:  (...0) Individual address 

Re: [cifs-discuss] bug when processing wildcards for file names with unicode

2012-04-10 Thread SSE - Martin Riethmüller

 The glob is evaluated on the client, even with SMB, IIRC.  That would
 mean the problem is on the client.


But when I copy my test-directory of my first post to a linux box, shared with 
samba version

SSEMWS:~ # smbd -V
Version 3.0.28-0.5-1657-SUSE-CODE10

everything is working fine (on exactly the same W7-client!):

C:\dir \\ssemws\kunden\temp\test\
 Datenträger in Laufwerk \\ssemws\kunden: ist kunden
 Volumeseriennummer: 0B79-0989

 Verzeichnis von \\ssemws\kunden\temp\test

10.04.2012  10:45DIR   .
10.04.2012  10:45DIR   ..
06.10.2011  11:14 0 FILENAME1_TEXT.txt
06.10.2011  11:15 0 FILENAME3_ÄÄÄ.txt
08.11.2011  12:15 0 FILENAME4_üöäÜÖħ.txta
08.11.2011  11:50 0 not_a_folder
06.10.2011  11:15DIR   FOLDER1
06.10.2011  11:15 0 FILENAME2_.txt
08.11.2011  11:50DIR   is.a.folder.txt
06.10.2011  11:15DIR   FOLDER2
   5 Datei(en),  0 Bytes
   5 Verzeichnis(se), 441.759.458.304 Bytes frei

C:\dir \\ssemws\kunden\temp\test\*_*.*
 Datenträger in Laufwerk \\ssemws\kunden: ist kunden
 Volumeseriennummer: 0B79-0989

 Verzeichnis von \\ssemws\kunden\temp\test

06.10.2011  11:14 0 FILENAME1_TEXT.txt
06.10.2011  11:15 0 FILENAME3_ÄÄÄ.txt
08.11.2011  12:15 0 FILENAME4_üöäÜÖħ.txta
08.11.2011  11:50 0 not_a_folder
06.10.2011  11:15 0 FILENAME2_.txt
   5 Datei(en),  0 Bytes
   0 Verzeichnis(se), 441.758.746.624 Bytes frei

I've also tested another linux box with samba-Version

ssetk1:~ # smbd -V
Version 3.0.10-SUSE

giving the same results as above: everything is working fine on the same 
client. Only the Solaris-based cifs-servers do have the problem.

Thanks,
Martin


___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] bug when processing wildcards for file names with unicode

2012-04-10 Thread Gordon Ross
On Thu, Apr 5, 2012 at 5:05 PM, Nico Williams n...@cryptonector.com wrote:
 The glob is evaluated on the client, even with SMB, IIRC.  That would
 mean the problem is on the client.

Actually, that pattern match happens on the server, as part of the SMB
FindFirst/FindNext operations.
___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] bug when processing wildcards for file names with unicode

2012-04-05 Thread Nico Williams
The glob is evaluated on the client, even with SMB, IIRC.  That would
mean the problem is on the client.
___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss