Re: [cifs-discuss] bug when processing wildcards for file names with unicode
> 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 a
Re: [cifs-discuss] bug when processing wildcards for file names with unicode
And here the capture of the "dir *_*.*" on Solaris.
Martin
SOLARIS
---
2813:02:35 11.04.20122.9602209System192.168.237.110
192.168.237.121SMBSMB:C; Nt Create Andx, FileName = \
{SMB:10, SMBOverTCP:3, TCP:2, IPv4:1}
2913:02:35 11.04.20122.9604449System192.168.237.121
192.168.237.110SMBSMB:R; Nt Create Andx, FID = 0x0002 (\@#28)
{SMB:10, SMBOverTCP:3, TCP:2, IPv4:1}
3013:02:35 11.04.20122.9606116System192.168.237.110
192.168.237.121SMBSMB:C; Transact2, Query FS Info, Query FS
Attribute Info (NT){SMBOverTCP:3, TCP:2, IPv4:1}
3113:02:35 11.04.20122.9607868System192.168.237.121
192.168.237.110SMBSMB:R; Transact2, Query FS Info, Query FS
Attribute Info (NT), FS = NTFS{SMBOverTCP:3, TCP:2, IPv4:1}
3213:02:35 11.04.20122.9608462System192.168.237.110
192.168.237.121SMBSMB:C; Close, FID = 0x0002 , FileName=\@#28
{SMB:10, SMBOverTCP:3, TCP:2, IPv4:1}
3313:02:35 11.04.20122.9610243System192.168.237.121
192.168.237.110SMBSMB:R; Close, FID = 0x0002 , FileName=\@#28
{SMB:10, SMBOverTCP:3, TCP:2, IPv4:1}
3413:02:35 11.04.20122.9612091System192.168.237.110
192.168.237.121SMBSMB:C; Nt Create Andx, FileName = \
{SMB:11, SMBOverTCP:3, TCP:2, IPv4:1}
3513:02:35 11.04.20122.9614173System192.168.237.121
192.168.237.110SMBSMB:R; Nt Create Andx, FID = 0x0002 (\@#34)
{SMB:11, SMBOverTCP:3, TCP:2, IPv4:1}
3613:02:35 11.04.20122.9615382System192.168.237.110
192.168.237.121SMBSMB:C; Transact2, Query FS Info, Query FS
Volume Info (NT){SMBOverTCP:3, TCP:2, IPv4:1}
3713:02:35 11.04.20122.9617153System192.168.237.121
192.168.237.110SMBSMB:R; Transact2, Query FS Info, Query FS
Volume Info (NT), Label = volumes{SMBOverTCP:3, TCP:2, IPv4:1}
3813:02:35 11.04.20122.9617732System192.168.237.110
192.168.237.121SMBSMB:C; Close, FID = 0x0002 , FileName=\@#34
{SMB:11, SMBOverTCP:3, TCP:2, IPv4:1}
3913:02:35 11.04.20122.9619601System192.168.237.121
192.168.237.110SMBSMB:R; Close, FID = 0x0002 , FileName=\@#34
{SMB:11, SMBOverTCP:3, TCP:2, IPv4:1}
4013:02:35 11.04.20122.9653755System192.168.237.110
192.168.237.121SMBSMB:C; Nt Create Andx, FileName =
\temp\TEST{SMB:12, SMBOverTCP:3, TCP:2, IPv4:1}
4113:02:35 11.04.20122.9656314System192.168.237.121
192.168.237.110SMBSMB:R; Nt Create Andx, FID = 0x0002
(\temp\TEST@#40){SMB:12, SMBOverTCP:3, TCP:2, IPv4:1}
4213:02:35 11.04.20122.9658161System192.168.237.110
192.168.237.121SMBSMB:C; Transact2, Find First2, Full Directory
Info (NT), Pattern = \temp\TEST\*_<"*{SMB:13, SMBOverTCP:3, TCP:2,
IPv4:1}
4313:02:35 11.04.20122.9661053System192.168.237.121
192.168.237.110SMBSMB:R; Transact2, Find First2, Full Directory
Info (NT){SMB:13, SMBOverTCP:3, TCP:2, IPv4:1}
4413:02:35 11.04.20122.9671752System192.168.237.110
192.168.237.121SMBSMB:C; Close, FID = 0x0002 ,
FileName=\temp\TEST@#40 {SMB:12, SMBOverTCP:3, TCP:2, IPv4:1}
4513:02:35 11.04.20122.9673486System192.168.237.121
192.168.237.110SMBSMB:R; Close, FID = 0x0002 ,
FileName=\temp\TEST@#40 {SMB:12, SMBOverTCP:3, TCP:2, IPv4:1}
4613:02:35 11.04.20122.9683525System192.168.237.110
192.168.237.121SMBSMB:C; Nt Create Andx, FileName =
\temp\TEST{SMB:14, SMBOverTCP:3, TCP:2, IPv4:1}
4713:02:35 11.04.20122.9686227System192.168.237.121
192.168.237.110SMBSMB:R; Nt Create Andx, FID = 0x0002
(\temp\TEST@#46){SMB:14, SMBOverTCP:3, TCP:2, IPv4:1}
4813:02:35 11.04.20122.9687799System192.168.237.110
192.168.237.121SMBSMB:C; Transact2, Query FS Info, Query Full FS
Size Info{SMBOverTCP:3, TCP:2, IPv4:1}
4913:02:35 11.04.20122.9705026System192.168.237.121
192.168.237.110SMBSMB:R; Transact2, Query FS Info, Query Full FS
Size Info{SMBOverTCP:3, TCP:2, IPv4:1}
5013:02:35 11.04.20122.9705979System192.168.237.110
192.168.237.121SMBSMB:C; Close, FID = 0x0002 ,
FileName=\temp\TEST@#46 {SMB:14, SMBOverTCP:3, TCP:2, IPv4:1}
5113:02:35 11.04.20122.9707849System192.168.237.121
192.168.237.110SMBSMB:R; Close, FID = 0x0002 ,
FileName=\temp\TEST@#46 {SMB:14, SMBOverTCP:3, TCP:2, IPv4:1}
Frame: Number = 42, Captured Frame Length = 172, MediaType = ETHERNET
- Ethernet: Etype = Internet IP
(IPv4),DestinationAddress:[00-25-90-1E-BB-20],SourceAddress:[00-01-80-7E-94-A5]
- DestinationAddress: 002590 1EBB20 [00-25-90-1E-BB-20]
Rsv: (00..)
UL: (..0.) Universally Administered Address
IG:
Re: [cifs-discuss] bug when processing wildcards for file names with unicode
> 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.3>dir Datenträger in Laufwerk H: ist volumes Volumeseriennummer: 75D1-D7F8 Verzeichnis von H:\temp\TEST\8.3 11.04.2012 14:07 . 12.12.2011 16:57 .. 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.3>dir *_*.* 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
On 04/10/12 08:22, Chris Ridd wrote: On 10 Apr 2012, at 16:13, SSE - Martin Riethmüller wrote: If you sniff the CIFS traffic in the two cases, can you see what each client is doing and what each server is sending back? Chris I've never done this before but I want to do my best... Which tool should I use for network sniffing on W7 ? Martin I would sniff it on the server - snoop on Solaris, tcpdump on Linux. Use "-s 0" in both cases and write the output to a file. Then use Wireshark (on any convenient machine) to open those saved files... I think the Windows version of Wireshark will also install something that will let you sniff traffic. Chris ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss Yes, you can use wireshark on the Windows client. You can also use netmon on the Windows client. ___ 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
If you have an 8.3 name that contains non-ascii unicode characters is it returned in the directory listing? Joyce On 04/05/12 04:13, SSE - Martin Riethmüller wrote: Hello, in all Solaris-versions I've tested until now (Nexenta, OpenSolaris, Oracle Solaris 10 + 11) the same serious bug seems to be in the Kernel-CIFS-Server. When a file name contains Unicode-characters and is longer than 8.3 the wildcard-search for filenames does not work correctly. Please have a look at an example to see the problem: A directory has this contents on a Solaris-cifs-share: Z:\TEST>dir Datenträger in Laufwerk Z: ist rpool Volumeseriennummer: 4E97-4F03 Verzeichnis von Z:\TEST 04.04.2012 12:39 . 04.04.2012 12:22 .. 06.10.2011 11:15 0 FILENAME3_ÄÄÄ.txt 06.10.2011 11:15 FOLDER1 08.11.2011 11:50 is.a.folder.txt 08.11.2011 12:15 0 FILENAME4_üöäÜÖħ.txta 06.10.2011 11:14 0 FILENAME1_TEXT.txt 06.10.2011 11:15 FOLDER2 08.11.2011 11:50 0 not_a_folder 06.10.2011 11:15 0 FILENAME2_.txt 5 Datei(en), 0 Bytes 5 Verzeichnis(se), 60.948.753.408 Bytes frei Now for example you want to get the files containing _ You will see this strange wrong behaviour: Z:\TEST>dir *_*.* Datenträger in Laufwerk Z: ist rpool Volumeseriennummer: 4E97-4F03 Verzeichnis von Z:\TEST 06.10.2011 11:14 0 FILENAME1_TEXT.txt 1 Datei(en), 0 Bytes 0 Verzeichnis(se), 60.948.753.408 Bytes frei The same directory copied for example onto an (NTFS) C:-Disk or even onto any linux-samba-share gives the correct result: C:\TEMP\TEST>dir *_*.* Datenträger in Laufwerk C: ist System Volumeseriennummer: 48E6-5F1D Verzeichnis von C:\TEMP\TEST 06.10.2011 11:14 0 FILENAME1_TEXT.txt 06.10.2011 11:15 0 FILENAME2_.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 5 Datei(en), 0 Bytes 0 Verzeichnis(se), 35.015.794.688 Bytes frei The bug is not only occuring in the MS-DOS-dir-command but also in all Windows-API-Functions to read directories (FindFirstFile,FindFirstFileEx,...). It does not depend on the Windows Version. There are no ZFS/SMB/ZPOOL/... - settings that do change anything of this behaviour, I've tested nearly everything, it was frustrating. I'm searching for an solution of this problem for a very, very long time until now and I really hope that someone can confirm that this bug is existing and can give me an hint what needs to be done to fix it. Thanks, Martin ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss ___ 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
On 10 Apr 2012, at 16:13, SSE - Martin Riethmüller wrote: > > If you sniff the CIFS traffic in the two cases, can you see what each > > client is doing and what each server is sending back? Chris > > I've never done this before but I want to do my best... > Which tool should I use for network sniffing on W7 ? Martin I would sniff it on the server - snoop on Solaris, tcpdump on Linux. Use "-s 0" in both cases and write the output to a file. Then use Wireshark (on any convenient machine) to open those saved files... I think the Windows version of Wireshark will also install something that will let you sniff traffic. Chris ___ 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
> If you sniff the CIFS traffic in the two cases, can you see what each client is doing and what each server is sending back? Chris I've never done this before but I want to do my best... Which tool should I use for network sniffing on W7 ? 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
On 10 Apr 2012, at 10:20, SSE - Martin Riethmüller wrote: >> 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!): If you sniff the CIFS traffic in the two cases, can you see what each client is doing and what each server is sending back? Chris ___ 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
On Thu, Apr 5, 2012 at 5:05 PM, Nico Williams 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
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:45 . 10.04.2012 10:45 .. 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 FOLDER1 06.10.2011 11:15 0 FILENAME2_.txt 08.11.2011 11:50 is.a.folder.txt 06.10.2011 11:15 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
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
