On Sat, Dec 16, 2000 at 04:26:58PM -0600, Dan Nelson wrote:
> That's why dotlocking is recommended for locking mail spools. Both
> procmail and mutt will dotlock your mail file while it's being
> accessed.
Or Maildirs.
--
Jos Backus _/ _/_/_/"Modularity is not a hack."
In the last episode (Dec 16), Axel Thimm said:
> Wouldn't that mean, that you might cause data corruption if, say, I
> was to read my mail from a FreeBSD box over an NFS mounted spool
> directory (running under OSF1 in our case), and I decided to write
> back the mbox to the spool dir the same mom
Thanks for the fast reply.
On Thu, Dec 14, 2000 at 05:45:15PM -0500, David E. Cross wrote:
> As for "client" vs. "server", that is quite tricky since WRT NFS locking
> they are both client and server. The "server" side is done and requires no
> modifcations to the kernel. However a FreeBSD
Going with the lockd code on builder is great with me. The last I had
looked it had some of the same issues as the lockd developed here (no
handling of grace periods, etc.), so on a featureset we are even. The rpics
lockd has the advantage of being known by some of us to a much greater extent
th
:I'm not going to take such an action w/o the blessing of -core. :)
:
:--
:David Cross | email: [EMAIL PROTECTED]
:Lab Director | Rm: 308 Lally Hall
In regards to Jordan's message just a moment ago... you know, I *total*
forgot t
On Fri, Dec 15, 2000 at 12:09:32AM +0100, Thierry Herbelot wrote:
> Hello,
>
> I've recently seen in the NetBSD 1.5 release Notes that *they* claim to
> have a fully functional rpc.lockd manager : "Server part of NFS locking
> (implemented by rpc.lockd(8)) now works."
>
> could someone have a lo
I'm not going to take such an action w/o the blessing of -core. :)
--
David Cross | email: [EMAIL PROTECTED]
Lab Director | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Compute
Hello,
I've recently seen in the NetBSD 1.5 release Notes that *they* claim to
have a fully functional rpc.lockd manager : "Server part of NFS locking
(implemented by rpc.lockd(8)) now works."
could someone have a look at what our cousins have done and perhaps
import it in -current ?
Tf
* David E. Cross <[EMAIL PROTECTED]> [001214 14:45] wrote:
> I pruned the Cc: list a bit...
>
> One of the email messages that you quoted has the URL for the latest
> development of the lockd code. As far as tests go it appears to be mostly
> complete (there appears to be an issue with RPC64 on
I pruned the Cc: list a bit...
One of the email messages that you quoted has the URL for the latest
development of the lockd code. As far as tests go it appears to be mostly
complete (there appears to be an issue with RPC64 on little endian machines,
but I have not yet had a chance to crawl thro
Dear all,
rpc.lockd in FreeBSD suffers from a pubic server's lazyness --- It says it's
done the job, but never did anything besides talking...
Searching through the lists gives different stories. Some say that NFS locking
isn't really necessary, but what about locking critical situations like
de
11 matches
Mail list logo
