Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.sprintlink.net!in2.uu.net!newshub1.wanet.net!ucsnews!newshub.sdsu.edu!saturn!larryr From: larryr@saturn.sdsu.edu (Larry Riedel) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Linux Killer App (ksmbfs) Date: 4 Oct 1995 00:07:10 GMT Organization: San Diego State University Lines: 26 Message-ID: <44sj7e$enm@hole.sdsu.edu> References: <44cma4$fv4@hole.sdsu.edu> <44g8jj$51q@keltia.freenix.fr> <44h6qi$kbf@news.bu.edu> <44ha9d$9h0@mark.ucdavis.edu> <44nt2q$lnf@news.bu.edu> <44pgcj$ap@park.uvsc.edu> NNTP-Posting-Host: saturn.sdsu.edu X-Newsreader: TIN [version 1.2 PL2] Terry Lambert <terry@cs.weber.edu> wrote: > > We understand the problem. > > SMBFS is not the answer. > > If you want to write an SMBFS with the inherent limitations of > a restricted model, feel free. It would have less utility than > an smbclient broken out into several command line utilties along > the line of mtools. I don't know if SMBFS is or is not "the answer" to any "problem," but there are some things I can do more productively when remote files appear to be part of my local filesystem, even if there are some significant caveats and restrictions. > Personally, I'd rather solve the problem > than kludge around it; a planned kludge is not worthy of my efforts. If there were a kludge that I could predictably use more productively than the alternatives, I'd take the kludge. Larry