> > 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