[OpenAFS-win32-devel] Re: file locking
Matt Benjamin
matt@linuxbox.com
Wed, 20 Jul 2005 17:36:11 -0400
This is a multi-part message in MIME format.
--------------070606080302090504000003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Eric Williams wrote:
<snip stuff>
>the behaviour on the SMB client that i would expect is that LockFile and
>UnlockFile APIs would succeed, and would even return an indication of a
>conflict properly. however, these locks would not prevent reading/writing
>to the locked regions (being advisory, after all). asking for and
>receiving a lock should also cause a RXAFS_SetLock call, which should set
>a while-file advisory lock on the server. this is my interpretation of
>the code. as jeff noted earlier, however, he was not seeing the lock on
>the server-side.
>
>
>
>
Well, I think I observed that is the behavior, in fact. I didn't try to
write to a region locked by another process. If I understand correctly,
this must be a very odd behavior for a Windows client to see? Being
cheesy about it, I think the most useful point to the exercise is to
give msoffice applications a chance to detect a sharing conflict on
another host. So unless advisory locking w/whole-file lock in AFS won't
buy us that(?), there's your example of where advisory locking would be
useful. OTOH, if mandatory is of equivalent difficulty, and more
correct for the platform, maybe the CM shold aim for "natural?"
>that, and the idea of having keyed locks. the keys are useful for batch
>unlock operations. they also might be used in hosted-code (such as
>services sharing a process), because it helps enforce privilege. the i/o
>manager assigns the key, not the api caller. regardless of how they are
>used, they must become a part of the stored lock.
>
>
Ok
>
>
>>The time-period of validity throws me--seems to be a Windows CM-ism? I
>>didn't run into this in afs_lockctl, nor do I see it in afs.h,
>>afsint.xg, and so forth.
>>
>>
>
>i can't speak to this, but i believe jeff has addressed it. briefly
>reading the client code, it seems to assume that the server is timing out
>the lock.
>
>
yes, got it
>can locks be broken by the server, and is the client notified?
>
>
*sigh* Not even. And if it could, and it were, they would still be sad.
>eric
>_______________________________________________
>OpenAFS-Win32-devel mailing list
>OpenAFS-Win32-devel@openafs.org
>http://lists.openafs.org/mailman/listinfo/openafs-win32-devel
>
>
>
--
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI 48104
http://linuxbox.com
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
--------------070606080302090504000003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Eric Williams wrote:<br>
<snip stuff><br>
<blockquote cite="midPine.BSO.4.58.0507201625340.11288@citi.umich.edu"
type="cite">
<pre wrap="">the behaviour on the SMB client that i would expect is that LockFile and
UnlockFile APIs would succeed, and would even return an indication of a
conflict properly. however, these locks would not prevent reading/writing
to the locked regions (being advisory, after all). asking for and
receiving a lock should also cause a RXAFS_SetLock call, which should set
a while-file advisory lock on the server. this is my interpretation of
the code. as jeff noted earlier, however, he was not seeing the lock on
the server-side.
</pre>
</blockquote>
Well, I think I observed that is the behavior, in fact. I didn't try
to write to a region locked by another process. If I understand
correctly, this must be a very odd behavior for a Windows client to
see? Being cheesy about it, I think the most useful point to the
exercise is to give msoffice applications a chance to detect a sharing
conflict on another host. So unless advisory locking w/whole-file lock
in AFS won't buy us that(?), there's your example of where advisory
locking would be useful. OTOH, if mandatory is of equivalent
difficulty, and more correct for the platform, maybe the CM shold aim
for "natural?"
<blockquote cite="midPine.BSO.4.58.0507201625340.11288@citi.umich.edu"
type="cite">
<pre wrap="">that, and the idea of having keyed locks. the keys are useful for batch
unlock operations. they also might be used in hosted-code (such as
services sharing a process), because it helps enforce privilege. the i/o
manager assigns the key, not the api caller. regardless of how they are
used, they must become a part of the stored lock.
</pre>
</blockquote>
Ok<br>
<blockquote cite="midPine.BSO.4.58.0507201625340.11288@citi.umich.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">The time-period of validity throws me--seems to be a Windows CM-ism? I
didn't run into this in afs_lockctl, nor do I see it in afs.h,
afsint.xg, and so forth.
</pre>
</blockquote>
<pre wrap=""><!---->
i can't speak to this, but i believe jeff has addressed it. briefly
reading the client code, it seems to assume that the server is timing out
the lock.
</pre>
</blockquote>
yes, got it<br>
<br>
<blockquote cite="midPine.BSO.4.58.0507201625340.11288@citi.umich.edu"
type="cite">
<pre wrap="">can locks be broken by the server, and is the client notified?
</pre>
</blockquote>
<br>
*sigh* Not even. And if it could, and it were, they would still be
sad.<br>
<br>
<blockquote cite="midPine.BSO.4.58.0507201625340.11288@citi.umich.edu"
type="cite">
<pre wrap="">
eric
_______________________________________________
OpenAFS-Win32-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenAFS-Win32-devel@openafs.org">OpenAFS-Win32-devel@openafs.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openafs.org/mailman/listinfo/openafs-win32-devel">http://lists.openafs.org/mailman/listinfo/openafs-win32-devel</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI 48104
<a class="moz-txt-link-freetext" href="http://linuxbox.com">http://linuxbox.com</a>
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
</pre>
</body>
</html>
--------------070606080302090504000003--