[Samba] RE: [PATCH] smbfs readdir fix (CFT: NetApp, OS/2)

[Vlad Skarzhevskyy]

Urban,
 You are the man!
 I had this problem for a year now and was afraid to ask for help.

patch -p0 < smbfs-2.4.19-pre9-readdir.patch
make modules; make modules_install
modprobe -r smbfs; modprobe smbfs
mount -t smbfs .....;

tested 250 short name files, 1000 list of same dir  - OK
tested 250 long name files, OK 1000 list of same dir - OK
tested 550 long name files, 1000 list of same dir - OK
tested 450 really long(120 chars) name files, 1000 list of same dir - OK
tested 1450 short name files, 1000 list of same dir  - OK
all testes default ttl and ttl=10

Run my own (scan file list to DB) system where I originally had this
problem.
Various directories with different number of files and different names.
It reads listing and compare it with the one stored in db.
~3000 files and 1500 directories.

  No Problem found in mounts from Windows 2000!!!!

  I believe that this fix deserve to be included into next version of samba
if it does not break other functionality!

  BUT
       I tried to test windows 98 mount.
       It does NOT work for me I could not see any listing from this mount
at all!
       mount stuck and I could not unmount it......
       I don't know if in particular this path of previous set
		00-smbfs-2.4.18-codepage.patch.gz
		01-smbfs-2.4.18-lfs.patch.gz
		02-smbfs-2.4.18-unicode.patch.gz
        Introduced the problem....
       Do you want me to find this out?

In general how to remove mount that stuck 	?
I could not list this mount dirs. It just stay forever when I run ls
/mnt/mymountpoint
The only way I could unmount it is cold reboot.
This may be another problem of smbfs, but this could be next fix...

Regards,
Vlad

-----Original Message-----
From: Urban Widmark [mailto:urban at teststation.com]
Sent: Saturday, June 22, 2002 7:14 PM
To: Vlads
Cc: samba at lists.samba.org; David.Lee at bisus.com
Subject: [PATCH] smbfs readdir fix (CFT: NetApp, OS/2)


On Fri, 21 Jun 2002, Vlads wrote:

> Urban,
>  I made a tcpdump files for each request.
>  Look like windows do no return the missing file in any tcp packet....

There are some differences in how the requests are made:
1. smbfs does not understand the lastname data for FIND_NEXT when in
   infolevel 260 and does not use it in the next request. NT4/win2k does.
2. smbfs sets the continue bit to tell the server to continue from the
   last search, NT4/win2k does not.

Even with your scripts, Vlad, I can't always trigger this error so I don't
know if I have fixed anything yet. But I have not managed to get the error
after changing the two differences above.

The attached patch is experimental. It will probably not work if you use
smbfs with unicode support.

It is meant for 2.4.19-pre9 (+- a few pre versions), or 2.4.18 with
00-smbfs-2.4.18-codepage.patch.gz [1]

Please test and let me know if it works.


smbclient does the same thing so it would be hit by this too. The fix is
similar and if this works, perhaps you'd be interested in verifying that
too.

Other than some extra padding bytes, I can't find anything wrong with the
smbfs requests and it looks to me like a NT4/win2k bug with the continue
bit (especially given the randomness of the error).

If someone reading this is a NetApp or OS/2 user, your feedback on this
patch would be valued. I think the change for (1) breaks at least some
NetApp versions since they (IIRC) let the lastname offset point directly
to the filename and not the record.

/Urban

[1] http://www.hojdpunkten.ac.se/054/samba/00-smbfs-2.4.18-codepage.patch.gz