On Tue, Jan 21, 2003 at 07:36:28PM -0500, Neil Sequeira wrote: > On January 21, 2003 05:38 pm, Claudio Jeker wrote: > > Thanks for the patches, I will add variatioins of both. See > > attached patch. > > > > I've patched qmail-reply.c with your improved patches and will > continue testing against that. I had to add a mini-change into > recent_update() - "for(; size > MAX_SIZE; )" changed to "for(; n > > MAX_SIZE; )". >
Damn it. I should not post patches around midnight. > > The main problem with the NOTYET stuff is that multiple concurrent > > accesses to the .qmail-reply.db file will dump some users (by > > overwriting a just written file with a new file). I'm not sure if > > we should use the maildir++ approach with timestamps or if it is > > better to use file locking (which sucks over NFS). Perhaps we can > > also ignore it and some senders get more than one reply in the > > REPLY_TIMEOUT time. > > Would it be dangerous to always use the filename .qmail-reply.db.tmp > as the temp file, then check for the existence of that file before > updating .qmail-reply.db? ie. if .qmail-reply.db.tmp exists, then > sleep for a random number of seconds and try again up to the x minute > timeout period. That way if it exists it means someone else is > trying to update the db and we wait until they finish before doing > the current update - if the timeout expires, then just ignore the > update and move on. Not sure what nasty side-effects that could have > (could the potential race be eliminated? would it really matter?). > What happens if the file is not removed? I think the idea is good and I will try to make it that way. > Considering how critical this is (not), ignoring it might not be so > bad - if someone wants to enable this feature, then having occasional > duplicate replies is better than always having duplicate replies. > Time will tell... -- :wq Claudio
