Mike Bydalek wrote: > Jeffrey Altman wrote: >> In 1.4.1 the Server fully implements byte range locking. However, >> the byte range locks are not backed by AFS locks. >> > This may sound like a silly question, but do the byte range locks need > to be backed by AFS locks, or is having byte range locking enough for a > database?
If you have two users on separate machines and each one attempts to open the same file in AFS with byte range locks, and each user is told you may have an exclusive lock on this portion of the file and there are no locks obtained on the AFS server, then the two clients will both go on their merry way overwriting the data in use by the other one. Byte range locks on the client without backing by the server makes them for the most part useless. The only thing they are good for is to prevent two users on a Terminal Server or two applications being run by the same user on the same machine from stepping on each other. >> After 1.4.1 ships we will release 1.5 which will be a development >> release. This release will experiment with backing the byte range >> locks with AFS file locks. However, it will only be safe to use when >> all of the clients accessing the files support the locks. >> > Sure, this makes sense. >> >>> The catch-22 is that since I'm using Kerberos for authentication, I >>> can't get peer to peer sharing working because Windows is looking for a >>> domain controller (I think), and can't find one. I know this isn't >>> really an OpenAFS question, but I'm hoping that someone else out there >>> will have a similar setup with a suggestion on how I can share these >>> Quickbooks files. >>> >> >> XP Workstation shares require that either a domain account be used or >> a local account. The user connecting to the share must know the name >> and password of the account in question. NTLM will be used unless you >> have disabled it by policy. >> >> > The problem I am having is that Windows doesn't know where to look for > the user accounts because it's on a Kerberos domain - not a Windows > domain, yet remains in "workgroup mode." I may have to move this to the > Kerberos list, but I just thought I would ask since I'd be very > surprised if no one else was using that type of setup. >> Jeffrey Altman >> > Thanks, > Mike You need to fully specify the account names. If your workgroup is WORKGROUP and your machine name is MACHINE and your account name is USER, then you need to attach to the share with NET USE <drive> <UNC> /USER:MACHINE\USER <password> If you are attempting to use the Kerberos identity, you are probably out of luck because the KDCs do not support referrals and the mappings from Kerberos principal to local machine account are being done on the destination machine. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
