* DZ-Jay <dz(_at_)caribe(_dot_)net> [2004-08-07 06:59]:
Well, the problem with that, as I see it, is that the process
attempting to access the file from the remote system does *not*
interact with the filesystem on the other end, but its own local fs
and kernel conspire to make it transparent that its accessing a
local file, when in reality its going through the network.
Transparentcy does not imply a loss of control on the part of the
remote OS. This cannot be a transfer of control, but rather a
duplication of requests. You may be requesting access to a network
file through your local kernel, but that does not mean your kernel
does not have to ask the remote machine for access to the file. If
the control were transfered entirely to the machine making the
request, then there would be no need for the remote machine to run NFS
or any kind of service. In that case, such a request would fail
because the machine would not respond. At some point the request
*must* go through the kernel running on the machine containing the
file, and that kernal has the option to deny access.
In this case, its local fs and kernel *must* be aware of file access
restrictions, from across the other end of the network, and
therefore the kernel where the file resides would have to tell the
other kernel that the file is locked. And this is the limitation
mentioned by Google Kreme.
The kernel of the client to the request need not be aware of the
remote restrictions. It's entirely feasible for a kernel to blindly
request whatever network file it wants, and get a denial from the
remote server. If a kernel insists on knowing all the restrictions
and states of all the remote files in advance, then that's where the
flaw is. The kernel should be robust enough to be able to recieve
denials and error codes, and generate timeout messages, and then feed
that information back to the client app.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail