Date: Thu, 31 Oct 1996 16:38:08 -0800 (PST) From: Mark Crispin <MRC@Panda.COM> To: chat@freebsd.org, "Marc G. Fournier" <scrappy@ki.net> Cc: current@freebsd.org Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <MailManager.846808688.5917.mrc@Ikkoku-Kan.Panda.COM> In-Reply-To: <Pine.NEB.3.95.961031191405.12546D-100000@quagmire.ki.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Oct 1996 19:22:20 -0500 (EST), Marc G. Fournier wrote: > 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... Why are you hung up on "fallback"? The code does all known forms of locking, independently of whether or not another form fails. I don't know how many times I've told you this. Apparently it still hasn't sunk in. What does it mean for fcntl() or flock() to "fail"? The system call returns success always (see below) on a blocking lock. That doesn't mean that you have a useful lock; perhaps the local mail delivery program doesn't pay attention to it. That doesn't even mean you have a lock at all -- on most BSD systems flock() is a no-op if the file is NFS. > 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... This is incorrect. Please re-read the paragraph beginning "What does it mean for fcntl() or flock() to fail". > Can't you test whether a locking method succeeded or not? No. This is what I am trying to tell you. > 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(). You misunderstand the meaning of the -1 return. A -1 return from flock()/fcntl() happens for one of only three reasons: 1) Your code is broken; you called it with bad arguments. 2) You have the misfortune of using one of the broken UNIX variants which has a systemwide limit on the number of locks, and that limit got popped. 3) Another process has the lock, and you are not blocking. In none of these three cases is it appropriate to "try the next method". Case (1) doesn't happen with debugged code. Case (3) doesn't happen if you are blocking (the process will wait until it gets the lock). So that only leaves case (2), which fortunately doesn't happen on most systems. A 0 return from flock()/fcntl() happens for one of two reasons: 1) you got the lock 2) the file is NFS and this OS variant no-ops locks over NFS. In other words, for all practical purposes, the system call always "works". On most UNIX variants, doing so accomplishes nothing useful, since mail delivery looks for a .lock file. > If you feel that a .lock > file is the preferred locking method, make that the first lock tha tis > attempted... It doesn't matter what order things are executed. The ability or inability to create a .lock file says nothing as to whether or not a system call lock should be applied. The ability to apply a system call lock says nothing as to whether or not a .lock file should be applied.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MailManager.846808688.5917.mrc>