>
> > 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
>
>
>
Try Kernel version 1.3.57. I have found it to be very stable. It may
solve you problem.
-----------------------------------------------------------------------------
Andrew Cameron
Internet : andrew@andy.alt.za
X.400 : C=ZA G=Andrew S=Cameron Admd=TELKOM400
----------------------------------------------------------------------------