[OpenAFS] File locking

Jeffrey Altman jaltman@secure-endpoints.com
Fri, 15 Jul 2005 11:13:25 -0400


This is a cryptographically signed message in MIME format.

--------------ms040101030002000303010209
Content-Type: multipart/mixed;
 boundary="------------010301050903060907050206"

This is a multi-part message in MIME format.
--------------010301050903060907050206
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I believe Matt is working on implementing something like this for the
Unix/Linux AFS clients.  However, no one at the present time is working
on an implementation for the Windows clients which is what you require.
Normally I would be the one to do it but I will not have time to do so
for several months.   There are other higher priority efforts that I
must work on:

 * helping get the OpenAFS 1.4 release out the door so there is a
   truly "stable" Windows release that will not suffer from unfortunate
   regressions due to new development

 * working on the rxgk security provider so there is the ability to
   use something other than single DES for authentication and
   data confidentiality

 * porting to 64-bit windows

 * adding support for the Unicode version of the CIFS/SMB protocol
   so that we can have large file support, dfs interoperability,
   Unicode path name support, etc.

Byte range locking is important but it is considered to be of slightly
lower priority.   In any event, even if I found a few days to implement
it.  It would not be in the initial 1.4 release.  It would be nice to
get it implemented before the end of the year.

Jeffrey Altman


Daniel Wood wrote:

> Hi all,
>  
> I am looking into implementing OpenAFS over a network comprised mainly
> of Windows clients.  Having installed v1.3.84 on a Linux server, the
> system is working fine so far.  The ability to manipulate volumes (such
> as moving between servers) to such an extent is particularly useful!
>  
> I was wondering what the progress was as regards byte-range locking. 
> Having searched a lot on the subject of file locking (and having had to
> learn a few things!), I have determined that OpenAFS utilises advisory
> whole-file locking but not byte-range locking.  Thus Windows
> applications such as Microsoft Office which utilise byte-range locking
> are very dangerous on an AFS network due to the fact that two
> applications can read/write to a file.  As an aside, why do Office apps
> use byte-range locking when they effectively lock the whole file?
>  
> Having looked at archived mailing list messages referring to Stage 1/2
> locking in AFS, I was curious as to the status of any work so far? 
> Ideally (and assuming I'm vaguely right!) a mechanism whereby a file is
> locked on the server to prevent writes (and either reads as well or
> notifying the user the file is read-only as per Office) whilst enabling
> byte-range locks in the cache would suit our purposes, since we use
> shared drives where multiple users will access documents but must not be
> allowed to change them at the same time.  This I believe is referred to
> as Stage 1?
>  
> I get the impression that work on this would be at a tangent to the way
> AFS works, however that Stage 1 is feasible?
>  
> Any corrections to my technical knowledge are most welcome, and any
> thoughts on a timescale in which this might be done if it can be done
> would be nice (though I do realise that's a hard thing to answer!).
>  
> Without implementation of this feature I don't think we will be able to
> use OpenAFS which is a shame because it does it's job well!  I don't
> think we can risk the possible loss of information it could cause, even
> if it is a somewhat unlikely prospect.
>  
> Thanks for your time,
>  
> Dan
> 
> 
> ------------------------------------------------------------------------
> 
> 
> This e-mail and the information contained is confidential and is intended solely for the person to whom it is addressed.
> If you are not the intended recipient or have received it in error we would appreciate a prompt notice that it has been wrongly despatched and will reimburse any reasonable cost involved in notifying us. We thank you for your help in this regard. 
> We would also advise that you should not use, disclose or copy this information in any medium, as if you do, you may be breaking the law and thereby incurring liability.
> We do not accept any liability to any third party acting or failing to act on, or on any information contained in this e-mail

--------------010301050903060907050206
Content-Type: text/x-vcard; charset=utf-8;
 name="jaltman.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="jaltman.vcf"

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:Secure Endpoints Inc.
adr:;;255 W 94TH ST PHB;NEW YORK;NY;10025;United States
email;internet:jaltman@secure-endpoints.com
title:President
tel;work:+1 212 769-9018
x-mozilla-html:TRUE
url:http://www.secure-endpoints.com
version:2.1
end:vcard


--------------010301050903060907050206--

--------------ms040101030002000303010209
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC
AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3
WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT
SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k
cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/
bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM
S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm
RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX
wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD
6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs
dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA
A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L
IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G
y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB
BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w
NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE
KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI
hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa
bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE
APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q
IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj
qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25
XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG
A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK
i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt
9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/
MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM
V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z
dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD
VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv
bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5
WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk
LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2
vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9
A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw
EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0
ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R
BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ
Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN
d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG
A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA3MTUxNTEzMjVaMCMGCSqG
SIb3DQEJBDEWBBQ8k8s3EM+SobkggdlBVM2JmnTQUTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC
AQBB6uBETSFLt7LVqJIVU/b0rVVBy3YiGD8FDNgrG7OLvuJtbl0afdo4xEkk7K2l0mlp8/6/
m+I5CP28JBW6rtXOuv2lKgXLTYBzTzwtN8zcWlelXViGv96+HCIe9HSm2P9dUUBtmdsJnERs
65EhWX4OgXvZQ02Sk0sqlHiiXhQTLtWOqDq7Kfxv5TKxAaAEK7OG2TDwhcl9RjGMx31K1LxU
pxygZhPxQBb90fhjbQ1wT8GXLWf/6yItK1Wk+TEWkt6wBau6XtW825pss0GB7WCKJjkc1/eQ
X7W8ldMTfWXr9CyYR2kkMqxQn5Iac9fe+FIC8/bf0IbW13xAFzkmTShqAAAAAAAA
--------------ms040101030002000303010209--