Good question - at some point I need to look at that. Clearly the structure is quite a bit different between the two. Most visibly the mount code is in kernel in mine (I have no mount helper yet as smbfs does - I was planning on adding some tcp name to ip address resolution code in the Samba utility "net" though so it could do a "net use" more gracefully). I noticed that smbfs is getting some activity - e.g. I saw that Unicode patches were added to smbfs so that is no longer a difference between the two. Another difference is that I have hardlink support - to be precise I added native Windows hardlink support in the cifs vfs and 1/2 implemented symbolic links (via windows style reparse points - the reparse points are detected but the follow link is not working). I don't implement the Unix extensions yet but will - I had focused on finding Windows equivalents for the Unix extensions which is harder than it sounds but important since Windows does not implement the Unix extensions.
A few other differneces - the cifs vfs uses native ip addresses and either 445 or the RFC1001 port rather than netbios naming as smbfs's helper uses. smbfs is quite a bit more stable and has reasonable backlevel interoperability (which is not a goal of the cifs vfs). The cifs vfs is designed only for those compliant with the SNIA CIFS Technical Reference or later to simplify the testing and maximize the Linux->Samba and Linux->Windows2000/XP/.NetServer function. I had hoped that in some sense it could serve as a "reference implementation" for the SNIA specification. Over time function between the two will probably diverge quite a bit more. I wanted to be much more aggressive in adding function and in design risks in the cifs vfs (ie more aggressive than I guessed we would be able to do in the smbfs which people rely on today to be stable) e.g. in adding function such as access control and Kerberos integration. Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: [EMAIL PROTECTED]
