Bug 2927 - erratic behavior with konqueror
erratic behavior with konqueror
Status: CLOSED INVALID
Product: Samba 3.0
Classification: Unclassified
Component: smbclient
3.0.20
x86 Linux
: P3 major
: none
Assigned To: Lars Müller
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-28 12:48 UTC by David Buck
Modified: 2006-04-07 19:13 UTC (History)
2 users (show)

See Also:


Attachments
tcpdump results (532.82 KB, application/bzip2)
2006-04-07 16:31 UTC, David Buck
no flags Details
tcp dumbs from the copy tests (532.33 KB, application/bzip2)
2006-04-07 16:35 UTC, David Buck
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Buck 2005-07-28 12:48:50 UTC
I have noticed (as well as many of my colleagues) that when we are viewing a
directory with many files (in the hundreds or above) in konqueror, konqueror
will display an amount close to, but rarely exact, to the amount of files there
really are in the directory.  Refreshing the directory will change that amount,
but usually not to the correct number.
Comment 1 David Buck 2005-07-28 12:54:34 UTC
Sorry.  More Information:

I had a Dual processing Windows2000 machine mounted at startup and was viewing
the files from there.  My colleagues and I are running SuSE-based systems (NLD9,
SuSE 9.3, 9.2, etc...)

Thanks,
Dave
Comment 2 Gerald (Jerry) Carter 2005-09-29 07:46:03 UTC
This should be fixed in 3.0.20.
Comment 3 Gerald (Jerry) Carter 2005-09-29 07:46:17 UTC
closing
Comment 4 David Buck 2006-04-05 20:18:52 UTC
I am now running SuSE 10.0, and the same thing seems to happen (the konqueror behavior) when viewing a remote directory with lots of files in them.

I also noticed that when I did a listing ('ls') of a remote directory using a bash shell, then compared it to a local listing of the same directory copied over (making sure that EVERY file was copied) a few things occured:

1. The remote listing would randomly miss only 1 file in the output, even though the file was there.

2. The remote listing would randomly miss a couple files at the start of the output, then would consistently miss the 39th file.  I have seen something similiar before in Samba 3.0.13 where copying a huge amount of files from a directory would result in missing the 41st file and every 39th file thereafter.

3. And lastly, the listing would come out just fine....  about 1 out of 4 tries for me.

The directory in question had 951 xml files and amounted to about 9.7MB.

My system used to run Samba 3.0.20b but was patched to 3.0.20 with a SUSE patch released.

I am now running kde 3.5.2
The remote machine is a dual processing Windows 2000 workstation which is mounted at startup.
Comment 5 David Buck 2006-04-05 20:26:52 UTC
One more thing.  I just tried to delete all the files in the folder with 951 xml files, and it left behind the 21st file, the 32nd, and starting with the 125th, every 39th file thereafter.  Coincidence?  I think not....
Comment 6 Gerald (Jerry) Carter 2006-04-06 05:46:51 UTC
This has got to be libsmbclient and not smbclient. 

Lars, since this is from a novell.com address, could you follow up?
Comment 7 David Buck 2006-04-06 18:02:43 UTC
I have just installed the newest samba binaries (ver. 3.0.22) for SUSE 10.0 and the same problems exist; including the copying of files, not just removing and listing.  Konqueror and nautilus and JEdit all have the file browsing problem with not showing the correct amount of files
Comment 8 Jeremy Allison 2006-04-06 20:08:46 UTC
This looks like a libsmbclient bug. Please log this at the novell bugzilla. We'll need to track it there.
Jeremy.
Comment 9 David Buck 2006-04-06 21:06:58 UTC
Are you saying that this bug might be a SUSE bug as well?  I am trying to add it at the bugzilla here, but there is no samba product to log it under so I will do so under SuSE Linux 10.0.
Comment 10 Jeremy Allison 2006-04-06 22:08:00 UTC
SuSE uses this component of Samba (libsmbclient). So if it's a Samba.org bug it's also a SuSE bug.
Jeremy.
Comment 11 David Buck 2006-04-06 22:15:16 UTC
Ok the bug is up at bugzilla.novell.com.  It is bug #164326.
Comment 12 Derrell Lipman 2006-04-06 22:40:47 UTC
The following information will help greatly in tracking down this problem:

- What version(s) of Windows is konqueror trying to enumerate files on (or delete files from)?  Win98? XP Pro? etc.

- It sounds like you can reproduce this problem reasonably easily.  Please attach to this bug network traces of both a successful and an unsucessful attempt to enumerate files in the same folder.  (Preferably one trace file showing a success and a different trace file showing a failure.)  We need raw network traces, not printed (ascii) versions.  To create the network traces, you can use the following command:

  tcpdump -s 0 -w outputfile.pcap

When you provide these traces, please let us know what file(s) are missing in the failed attempt that exist in the successful attempt.

Thanks!

Derrell
Comment 13 David Buck 2006-04-07 16:31:59 UTC
Created attachment 1849 [details]
tcpdump results

I had to remove the copy?.pcap files to get it down to size
Comment 14 David Buck 2006-04-07 16:35:00 UTC
Created attachment 1850 [details]
tcp dumbs from the copy tests

I couldn't include the 24 MB dump file for copy1.pcap
Comment 15 David Buck 2006-04-07 16:45:48 UTC
Ok. here goes....

To begin, I am remotely connected to a Windows 2000 server that has two partitions.  I have each partition mounted.  My tests involve a directory on each of these partitions, and a local directory.  They are as follows.  There really isn't any sensitive information as all the files I have been copying are made public anyways.

The first 2 are remote, 3rd one local.

/xeon/InfoRoot/Tids/InfoDocument/   original directory containing the 951 xml files.  I will call it directory 'a' from now on.

/xeonx/davetemp/                    directory on other partition that I performed my tests on (so to not harm the orig. data).  I will call it directory 'b' from now on.

~/temp/temp/                        local directory I copied files to.  I will call it directory 'c' from now on.

Ok, attached are all the tcpdumps,  except the copy1.pcap file, it is 24 MB, but is still described below; I am not sure how to give it to you if you want it.  All of the tests were done in bash except for the konqueror ones, and all were done remotely.

Bash commands used: 'cp', 'rm *', 'ls * > ~/temp/list1.txt', etc.  
I will explain each test I performed with the associated files:

copy1.pcap        try to copy 951 files from 'a' to 'b', 933 copied
remove1.pcap      tried to remove those 933 above from 'b', 922 removed
copy2.pcap        try to copy 951 from 'a' to 'c', 943 copied
copy3.pcap*       try to copy 951 from 'a' to 'c', 951 copied; however, 'c' already had 946 of the original previously copied
remove2.pcap      try to remove 951 from 'b', 938 removed
remove3.pcap      try to remove 951 from 'b', 941 removed
list1.pcap        listing of 951 files in 'b', 946 listed; found in list1.txt
list2.pcap        listing of 951 files in 'b', 942 listed; found in list2.txt
list3.pcap        listing of 951 files in 'b', 935 listed; found in list3.txt
list4.pcap        listing of 951 files in 'b', 937 listed; found in list4.txt
konqview1.pcap    first viewing of directory 'a', 931 (of 951) shown
konqview2.pcap    5 refreshes of 'a' showing 936, 933, 935, 936, and 934 files respectively
konqview3.pcap    second viewing of directory 'a', 934 files shown
konqview4.pcap    5 refreshes of 'a' showing 928, 931, 933, 930, and 936 files respectively
konqview5.pcap*   to get the directory 'b' to show all the files, I did this:  I started in 'b'; moved up one directory and navigated into a different one; clicked back and then selected 'b' again.  It showed 951. I did a refresh and it showed 927.  I am sorry all of this is in one dump

*successful attempts

Today wasn't a good testing day:
I tried close to a hundred times to get a correct listing of 'b', and I didn't succeed once. Nor did I succeed in a complete removal of 'b'.  I hope what I have sent is useful anyways.

I am glad you are taking the time to consider this problem seriously, it has been an hinderance to our team for some time now.
Comment 16 Derrell Lipman 2006-04-07 16:58:43 UTC
> To begin, I am remotely connected to a Windows 2000 server that has two
> partitions.  I have each partition mounted.  My tests involve a directory on
> each of these partitions, and a local directory.  They are as follows.  There
> really isn't any sensitive information as all the files I have been copying
> are made public anyways.
> 
> The first 2 are remote, 3rd one local.
> 
> /xeon/InfoRoot/Tids/InfoDocument/   original directory containing the 951 xml
> files.  I will call it directory 'a' from now on.
> 
> /xeonx/davetemp/                    directory on other partition that I
> performed my tests on (so to not harm the orig. data).  I will call it
> directory 'b' from now on.
> 
> ~/temp/temp/                        local directory I copied files to.  I
> will call it directory 'c' from now on.

Ok, I need a bit of clarification on this.  This looks like you have mounted the remote file systems using either smbfs or cifs.  If you are using smbfs, I don't believe that it is supported any more, and it is known to have bugs.  In that case, you should switch to using cifs instead, which is currently supported.

If you are already using cifs, then I'm the wrong person to look at this so I'll redirect this to the person who maintains cifs.

If these are not actually (remotely) mounted file systems, then I need to understand how you are accessing them as "/xeon/..." and "/xeonx/...".  Are those the paths you are typing into konqueror or the paths that it is presenting?

Let's figure out what portion of the code this is in, and then we'll try to get it resolved.

Thanks!

Derrell
Comment 17 David Buck 2006-04-07 17:04:39 UTC
Hmmmm...  They are mounted as smbfs.  I had no idea that was superceded by cifs.  Perhaps that will make all the difference in the world.  And yes, they are remotely mounted filesystem, one at /xeon, the other at /xeonx (sorry for the redundancy in my mounting abilities)

Oh yeah,
    I got the large tcpdump to upload at novell.  bug #164326

Comment 18 Jeremy Allison 2006-04-07 17:09:02 UTC
Ok, this is *not* a Samba bug - this is a kernel problem with smbfs it looks like. A little background - what confused us is that konqueror (and nautilus in gnome) have I/O helpers which can access remote filesystems via userspace calls into libsmbclient. If you're just accessing mounted filesystems then it's not going through any Samba code at all, but kernel module code. smbfs is unsupported in the current kernel, cifsfs is currently supported via Steve French at IBM. If you can reproduce the problem using CIFSFS you'll need to log a bug and the kernel team will have to fix it.
Jeremy.
Comment 19 David Buck 2006-04-07 19:13:52 UTC
ok thank you, cifs is working just fine.  I will stop writing about the bug here and continue only at novell.

davE