Bug 1609 - Directory listing fails on Win2k share
Directory listing fails on Win2k share
Product: Samba 3.0
Classification: Unclassified
Component: smbmount (unmaintained)
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2004-08-12 10:14 UTC by Jukka Holappa
Modified: 2005-05-11 05:01 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Jukka Holappa 2004-08-12 10:14:53 UTC
I have a very similar problem to bug 1251, but I'm not sure if it is similar
enough and I can't add a comment for it because "Only submitter can change
Hardware field to All".

I have Linux kernel version 2.4.27 with SAMBA 3.0.4 mounting a share from win2k
server. This share has one subdirectory that is not always listed correctly.

Problem was also happening with 2.4.26 and perhaps with earlier kernels.

Following log message (always the same) appears when read fails:
smb_proc_readdir_long: name=, result=-2, rcls=1, err=123

If some files are moved from directory, directory listing stars to work. There
just isn't any logic behind it... Copying some files to subdirectories, removing
them from main directory, moving them back and removing the created subdirectory
can make the directory listing work again. There is no single file that causes

This happens only with one subdirectory of one share. Everything else works

Filenames are listed correctly (I haven't checked the file count yet) when
another directory reads are made within one second after initial read. First one
returns 0 entries, others return lots of files.

When sniffing network traffic, it can be seen that first one is the only one
that actually fetches data from the server. Later directory listings come from
kernel cache.

When listing the same directory with smbclient, everything works correctly all
the time.

Problematic directory has nearly 1730 files in it.
Comment 1 Gerald (Jerry) Carter 2005-05-11 05:01:21 UTC
You appear to be using smbfs.  We don't maintain that 
kernel code.  You'll either need to get int touch with 
the smbfs maintainers or possibly try the linux cifs fs