"michael (m.d.) shubaly" <[EMAIL PROTECTED]> writes:
> Has anyone had a problem with any requirments of tools/scripts that
> require filelocking. If so was Transarc willing to give you a fix
> to what we call a "filelocking problem" or what your work arounds were.
AFS provides whole-file advisory locking, but not byte-range locking.
Translating to SunOS or Ultrix terms, we support flock(), but not
lockf(). If AFS receives a byte-range lock request, it returns
success, but prints out a kernel message something like this:
afs: byte-range lock ignored -- make sure no one else is using
this program
> For example we have a internal email system. We typically run several
> sessions of this system on our nodes, therefore the mail box(s) need
> to be locked by different sessions at different times depending if
> your reading in new mail or sending new mail. We use the rpc.lockd
> and rpc.statd to lock over NFS. As we understand it the AFS system
> will "lie" to you and say the file is locked and return a "0" code
> even though the file is not locked.
If the application is locking the entire file, you should have no
problems. If it's performing byte-range locking, your users should be
seeing the warning message and no locks are really being enforced.
> I have heard from a Sys Admin (IBM) that Transarc provided a fix
> for this problem. Has anyone else heard of this.
Hmm, I recently was scanning for a lock-related bug and saw one
submitted by IBM Austin. But that was for DFS, not AFS, and was
fixed and closed a long while back. Maybe if you can get more
details on the fix and send them into your AFS Customer Support
person, we can figure out what they were referring to.
Joe Jackson,
File Systems Product Support,
Transarc Corp.
