Re: Problem with smbfs (missing files/directories)

Scott Laird (scott@laird.com)
Thu, 14 Mar 1996 22:35:21 -0800

> Recently, one of our management types gave me a list of "directories"
> on "his system" that he wanted backed up. Suprise! One of the directories
> did NOT show up in an "ls" of a mount of his file system (mounted root
> directory of his "C:" drive). It also was NOT found by "find" when I ran
> "find . -print" on that directory! I could, however, "cd" to that directory
> even though it did not show up in a directory listing! i.e. When in his
> mounted directory "ls" did not show "foo" but "cd foo" succeeds and "ls" then
> shows the contents of "c:\foo"!
>
> That was strange enough! I then went to the samba client and did
> a listing of his drive. The missing directory and many other items showed
> up in the smbclient directory which did not show up in the smbfs directory
> listing! It looks like maybe somewhere from 5 to 10 percent (CWAG - Crude
> Wild Ass Guess) of the entries from this system do not appear in the smbfs
> listing which do appear in the smbclient listing. There does not appear to
> be anything "missing" from the smbclient listing, only the smbfs listing.
>
> This did NOT appear related to "hidden" files or "system" files
> since many of the missing entries where common files and directories while
> other "hidden" or "system" entries did appear in both.

I've had vaguely similar problems with smbfs, and I suspect they're
caused by a race condition somewhere in the smbfs directory code, but I
don't really have anything to base that on.

I, too, have tried backing up via tar over smbfs, and I've met with
some different problems. I've been trying to backup two (or more)
Windows 95 boxes at once for speed reasons. I've found that, from time
to time, I'll get a "file not found" error from tar. The weird thing
is that tar gives me an error complaining that it can't find /pc/A/foo,
when the file foo is _only_ found on system B, which was being backed
up at the same time. Somehow, an attempt to list a directory on A gave
tar a filename that only existed on B.

This has all happened running 1.3.37. I'd love to upgrade, but I
haven't been able to keep a more current kernel up for more than 24
hours at a time, while 1.3.37 stays up for weeks at a stretch without
major problems.

I can kill newer kernels (including 1.3.71) by simply mounting two
smbfs drives (on different systems) and running 'find /pc/A' and 'find
/pc/B' at the same time. I start getting protocol errors from smbfs
within 30 seconds, and the system appears slightly unstable after this.

I (unfortunately) don't have the exact error messages in front of me --
they're sitting at work, and I'm at home right now. I believe smbfs
was complaining about receiving more bytes than the protocol told it to
expect, but that's from memory. I usually give better bug reports :-).

The system in question is an AMD 486DX4/100 on a ASUS PCI/I SP3G
motherboard. The system has 24 MB of RAM, one IDE Fireball, one
Baracuda (on the internal NCR-based SCSI port), one Connor DAT, and a
SCSI CD-ROM. It uses a WD Ultra Ethernet board and a Stealth 64 PCI
video card.

I'm using AMD to automount the smbfs disks, and that might be part of
my problem. I haven't had time to disable AMD and try mounting the
disks by hand yet, and I probably won't for at least a week, due to
finals.

Is there _anyone_ out there who uses smbfs successfully for non-trivial
uses?

Scott