kernel support for open share modes
Michael B Allen
mba2000 at ioplex.com
Tue Feb 15 09:30:28 GMT 2005
On Mon, 14 Feb 2005 15:17:37 -0500
"J. Bruce Fields" <bfields at fieldses.org> wrote:
> Are there ideas for how to fix all this?
I believe it's generally accepted that there are certain incompatibilities
and limitations between the protocols and the POSIX APIs that prevent
proper coordination for many operations. POSIX simply isn't sophisticated
enough to implement a full featured userspace network filesystem in a
way that can communicate consistent systemwide state. POSIX was designed
to be simple (I guess because it's more secure).
The only possible way to make opening and setting additional file
attributes (e.g. deny modes) atomic is to perform both operations under a
lock that is respected by all parties involved. Locking within userspace
memory is sufficient for all clients of that application. But enties
outside of that application will, by default, have no knowledge of the
special locking and therefore it is simply not possible to coordinate
The only truely correct solution that can coordinate all entities
systemwide would require that code within the OS kernel be used to
control all access checks and set additional attributes atomically as
necessary. For Linux that might actually be reasonable thing to do but
note that in this instance it would be necessary to change the behavior
of the general file locking code as opposed to simply adding some VFS
hooks with a loadable module.
In practice it is not terribly common for an application to require this
level of corrdination however. It is usually simpler to simply force
the external application to be a client of the appliction maintianing
the locks as opposed to being a client of the local system. Meaning,
make your app do all filesystem I/O through Samba.
IRC - where men are men, women are men, and the boys are FBI agents.
More information about the samba-technical