Date: Thu, 31 Oct 1996 19:22:20 -0500 (EST) From: "Marc G. Fournier" <scrappy@ki.net> To: Mark Crispin <MRC@Panda.COM> Cc: current@freebsd.org Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <Pine.NEB.3.95.961031191405.12546D-100000@quagmire.ki.net> In-Reply-To: <MailManager.846796721.5917.mrc@Ikkoku-Kan.Panda.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Oct 1996, Mark Crispin wrote: > > You may not be able to know that fcntl() *will* work, but you can know > > .lock files *won't* work. > > So, what do we do now? We've determined that .lock files won't work. We no > longer have any guidance from run time tests. We have to choose a policy from > here. > > What are our choices? > 1) Error: "Lock failed, mailbox open aborted" > 2) Warning: "Lock failed, proceeding as if locked" > 3) Ignore the condition entirely. > Wait, this is stupid...why can't the code have 'fallback' options... if .lock fails, try lockin with fcntl(), if fcntl() fails, try with flock(), if flock() fails, *then* give an error message and abort... > In other words, it doesn't. The only thing it can do is be prepared. Good > Boy Scout software it is, yessiree. Apply every possible lock I can, that's > the trick. > Right, agreed...but as long as one of the three succeeds (in order of preferred locking method), don't print an error message, since a lock has been established... > > Again, I would prefer runtime configuration. If nothing else, because > > I use AMD to relocate my mail files to user accounts, and some are local > > and some are NFS mounted. > > This is EXACTLY what I'm doing for you, sir!! > > Now, do you have some magic run time test that could lead me to discriminate > between the two cases: > 1) system call locking was the right thing, don't worry. > 2) you really needed the .lock file, and the fool who set up the > system did so in a way that you don't have privileges to lock the > mail file. > If you did, I'd be happier than a pig in mud. > > About 6 years ago, a VAX BSD guru assured me that "turn off the annoying > message; if .lock file locking fails, system call locking is the right thing, > don't worry." I made the mistake of believing him. > Can't you test whether a locking method succeeded or not? My man page seems to indicate that a -1 return vali dmeans the lock was unsuccessful for an flock()...so if flock() == -1, try fcntl(). If you feel that a .lock file is the preferred locking method, make that the first lock tha tis attempted... > It is going to take a lot more than flaming to get me to trust the word of BSD > folks again. You're going to have to show me what I can do to make things any > better for you without reintroducing this problem in the remaining 99% of the > market. > The flamage in this discussion, until pretty much this message, has come from both sides :( As is usually the case in flammage.. Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.95.961031191405.12546D-100000>