recently, i have been working on a native windows openafs client. i am at the point of a mostly-stable, mostly-functional, read-only, anonymous client.
the client connects to windows through the io manager (using the installable filesystem kernel driver interface), rather than the abstracted smb layer. this should, in the end, allow faster access, more functionality, and better integration with windows, in general. its placement into the kernel gives more flexibility for security and earler loading at boot time. the ifs-layer kernel driver directly answers any io requests, so this prevents smb networking failures (the frustrating "network drive invalid" errors, etc.) from affecting afs. the standard cache manager code runs in userspace (as usual), for security reasons. the events in userland are dispatched much like the usual vnode ops, so the userland code lost all of its smb-bloat flavor and much of its windows flavor. code will be made available in useable form as soon as possible, and i will continue to develop in my spare time. eric williams _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
