Bug 8044 - Missing directory entries on CIFS-mounted Windows 7 share on Debian Squeeze (and previously on Lenny)
Missing directory entries on CIFS-mounted Windows 7 share on Debian Squeeze (...
Status: NEW
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.6
x86 Linux
: P5 normal
: ---
Assigned To: Steve French
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-28 20:24 UTC by Steve van der Burg
Modified: 2013-01-24 23:39 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve van der Burg 2011-03-28 20:24:26 UTC
Client is here:

vus2:~# uname -a
Linux vus2 2.6.32-5-686 #1 SMP Tue Mar 8 21:36:00 UTC 2011 i686 GNU/Linux

A user/password mount of a share on a Windows 7 server happens:

vus2:~# cat /proc/fs/cifs/DebugData
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 1.61
Active VFS Requests: 0
Servers:
1) Name: 192.168.2.191  Domain: HOME Uses: 1 OS: Windows 7 Enterprise 7601 Service Pack 1
        NOS: Windows 7 Enterprise 6.1   Capability: 0x1e3fc
        SMB session status: 1   TCP status: 1
        Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0
        Shares:
        1) \\familyroom7.local\pix Mounts: 1 Type: NTFS DevInfo: 0x20 Attributes: 0xc700ff
PathComponentMax: 255 Status: 0x1 type: DISK

        MIDs:

I seem to be missing pieces of any share that I mount from the Win7 host.  It's most noticeable on a 53GB share containing hundreds of directories.  Running strace on this (to ensure we have no ls-style sorting going on)

perl -le 'opendir(D,"/blah"); @f = readdir(D); closedir D; print $_ foreach @f;'

seems to indicate that getdents64, or whatever is calling it, isn't working correctly:

22501 open("/blah", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
22501 fcntl64(3, F_GETFD)               = 0x1 (flags FD_CLOEXEC)
22501 brk(0xa0cd000)                    = 0xa0cd000
22501 getdents64(3, /* 39 entries */, 32768) = 1248
22501 getdents64(3, /* 35 entries */, 32768) = 1360
...etc...
22501 getdents64(3, /* 31 entries */, 32768) = 1264
22501 getdents64(3, /* 0 entries */, 32768) = 0
22501 close(3)                          = 0
22501 write(1, ".\n", 2)                = 2
22501 write(1, "..\n", 3)               = 3
...etc (inside the group of 39 entries)...
22501 write(1, "2004_09_12\n", 11)      = 11   <--- last entry in 1st group
22501 write(1, "2005_01_25\n", 11)      = 11   <--- first entry in 2nd group
...etc...

The interesting part of this is that the missing directories live between the groups that getdents64 is returning.  The 'pix' directory on the server was recently copied there, so its entries are presorted.  I'm missing all the rest of the '2004_' directories, for example.  That is, some of my missing entries lie between the last entry returned by the 1st getdents64 call and the first entry returned by the 2nd getdents64 call.
If I remove a directory and try again, one of the missing entries appears in its place and the gaps all shift by one entry.

Here are all related packages on my system:

vus2:~# dpkg -l | grep smb
ii  libsmbclient                                            2:3.5.6~dfsg-3squeeze2       shared library for communication with SMB/CIFS servers
ii  smbclient                                               2:3.5.6~dfsg-3squeeze2       command-line SMB/CIFS clients for Unix
ii  smbfs                                                   2:4.5-2                      Common Internet File System utilities - compatibility package
vus2:~# dpkg -l | grep samba
ii  samba                                                   2:3.5.6~dfsg-3squeeze2       SMB/CIFS file, print, and login server for Unix
ii  samba-common                                            2:3.5.6~dfsg-3squeeze2       common files used by both the Samba server and client
ii  samba-common-bin                                        2:3.5.6~dfsg-3squeeze2       common files used by both the Samba server and client
ii  samba-doc                                               2:3.5.6~dfsg-3squeeze2       Samba documentation
vus2:~# dpkg -l | grep cifs
ii  cifs-utils                                              2:4.5-2                      Common Internet File System utilities
vus2:~#

I have also tried options like directio, serverino, noserverino, nounix, etc, and nothing changes.

...Steve
Comment 1 Steve van der Burg 2011-03-29 14:58:39 UTC
I just did a test with smbclient and I get different incorrect behaviour.  On my server I have 65 directories in the "pix" share whose names start with "2004".  When I use smbclient to attach, do an 'ls' and look at the results, I only see 34 of them.  If I do 'ls 2004_08*' I see all 23 directories that start with that prefix.

I can attach some strace output if that would be helpful.
Comment 2 Steve van der Burg 2011-04-21 19:44:14 UTC
Here's someone else with an Android CIFS client reporting what looks to be the same problem:   http://forum.xda-developers.com/showthread.php?t=1043448
Comment 3 Steve van der Burg 2011-04-21 19:53:32 UTC
And also: http://wdtvforum.com/main/index.php?topic=8422.0

A Windows XP client seems to be able to see all directories, although I need to test that again.
Comment 4 phil_nr 2013-01-24 23:39:12 UTC
Hello,

same problem. 
some directories are missing.

server:
Nas Synology - CS407 : Server=[Samba 3.2.8]
Nas Synology - DS212+ :Server=[Samba 3.6.6]

client :
Archlinux - 3.7.3-1-ARCH 0000001 SMP PREEMPT Thu Jan 17
Lazarus 1.0.4
Free Pascal Compiler version 2.6.0 [2013/01/14]
smbclient Version 3.6.10


media/test $cat /proc/fs/cifs/DebugData
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 2.0
Features: dfs fscache lanman posix spnego xattr acl
Active VFS Requests: 0
Servers:
1) Name: 192.168.1.5  Domain: MAISON Uses: 1 OS: Unix
	NOS: Samba 3.6.6	Capability: 0x80f3fd
	SMB session status: 1	TCP status: 1
	Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0
	Shares:
	1) \\192.168.1.5\test1 Mounts: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x50027
PathComponentMax: 255 Status: 0x1 type: DISK 

I can send some strace output if you want