Subject: Re: [netatalk-admins] movieplayer and such with afpd
From: a sun (asun@zoology.washington.edu)
Date: Mon Dec 15 1997 - 15:54:59 EST
okay, i believe byte locks should make possible a much improved
locking mechanism. how about doing the following for locks?
1) on an open fork, test access for read/write by attempting
to set a read/write lock. return a AFPERR_LOCK on a write
lock failure and AFPERR_ACCESS on a read lock failure.
2) if that succeeds, unset that lock and reset it to
correspond to the requested deny modes. i.e., deny read
gets a write lock and deny write gets a read lock. return
the appropriate error on failure to set that as well.
there's a minor race condition between 1 and 2, but i'm not sure how
important that is. in the worst possible case, #2 might fail when it
should have succeeded, resulting in an error message. currently,
afp_read, afp_write, afp_setforkparams, and deletefile set locks. i
believe that covers anything that goes through the adouble
library. needless to say, the old behaviour is the default one under
afs due to it lacking byte locks.
so, does anyone see any problems with this setup? am i missing places
that need byte lock protection?
-a
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:28:28 EST