Messages in this thread | | | Date | Fri, 15 Mar 1996 21:11:32 +0200 (GMT+0200) | From | Andrew Cameron <> | Subject | Re: Problem with smbfs (missing files/directories) |
| |
On Thu, 14 Mar 1996, Scott Laird wrote:
> > > 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
----------------------------------------------------------------------------
| |