Messages in this thread | | | From | "Michael H. Warfield" <> | Subject | Re: SMBFS: Question... | Date | Tue, 4 Aug 1998 08:52:03 -0400 (EDT) |
| |
Volker.Lendecke@sernet.de enscribed thusly: > engstad@intermetrics.com (Pal-Kristian Engstad) writes:
> > I'm sorry if I blamed the Samba team. They've done a great job, > > especially on the server side. However, when introducing user > > problems like this - they have to be blamed.
> If somebody is to be blamed -- it's me. I made the changes to smbfs > because I did not want netbios name lookup and password encryption in > the kernel or any different mount program, as smbclient already has > all of it. Then I finished my exams and had to start working. I simply > do not have the time to finish the job. I even did not compile a 2.1 > kernel for several months.
I really don't care who is "to blame" or not. I really appreciate anoyone who rolls up their sleaves and works on this stuff... I sent in a bunch of patches that either got into the cvs tree or encouraged someone to fix otherwise and commit to the cvs tree for the RedHat 5.1 stuff, including the smbumount program. I don't think the official release package contains any of those fixes as yet. There was one problem with the "dirent" conflicts between the kernel headers, the library headers, and smbmount that needed to be resolved in the header files, and I need to go back and double check that. Last I looked, the checked out cvs tree, including all of the smbfs related utilities, compiled under RedHat 5.1 with the possible exception of needing a patch to the <linux/smbfs.h> header file.
One real problem is that $#@$#@ syntax. I was chating with one of the Samba team (Luke) in my office yesterday, and he was commenting that he wasn't even sure he remembered WHY that syntax got changed. I seem to remember someone making the remark that since it was going to be a stripped down version of the smbclient (soon to be rolled back INTO the smbclient) that they were going with the smbclient syntax. No blame to be assigned, but this was a mistake. (Isn't 20:20 hindsight just lovely! :-) ) The existing syntax is difficult to impliment in other programs, such as autofs/automount, and totally screws backward compatibility. My guess is that nobody realize that smbmount was going to get routinely called from other programs and that they only problem they needed to deal with was "user education". Well... That proved to not be the case. Now we have to look at what got broke and what is the best way to deal with the consequences...
> I can only apologize, but I do not have the time to work on it > anymore. I think that I offered 'official' maintainership to Bill one > time, as he did great work on debugging smbfs. Bill, are you still > interested?
Who ever takes this over, can we revisit the backward / cross version compatibility issues? We need an smbmount program which can be called with consistant syntax from autofs and which will interoperate with the old, release version, 2.0.x smbfs as well as the development 2.1.x smbfs. That may be a very tall order and may not be readily achievable (that's why I wrote my smbmount.sh script to deal with the two separate mount programs) but I would like to see it at least looked at. Maybe a "wrapper" "smbmount" program would be appropriate, calling smbclient or the old smbmount as required. A "program" version of my script, if you would...
A way to hook this out of the "mount" command would definitly be sweet, let's just not loose sight of the compatibility issues this time.
Please?
> Volker
Regards to all...
Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |