a SMB an interface that has
> to implement NetBIOS calls, and those, in turn, externalize via
> the DOS INT 2A/2C mechanisms into the file I/O INTs, that SAMBA
> has to support mandatory locking.
How does it do this under FreeBSD? Does it implement it internally?
> In effect, it is an API
On Wednesday, 25 August 1999 at 19:53:22 -0400, Christian Kuhtz wrote:
> On Thu, Aug 26, 1999 at 09:09:33AM +0930, Greg Lehey wrote:
>> On Wednesday, 25 August 1999 at 6:05:11 -0400, Thomas David Rivers wrote:
>>>> All the files under Tandem's NSK has mandatory l
a SMB an interface that has
> to implement NetBIOS calls, and those, in turn, externalize via
> the DOS INT 2A/2C mechanisms into the file I/O INTs, that SAMBA
> has to support mandatory locking.
How does it do this under FreeBSD? Does it implement it internally?
> In effect, it is an API
On Wednesday, 25 August 1999 at 19:53:22 -0400, Christian Kuhtz wrote:
> On Thu, Aug 26, 1999 at 09:09:33AM +0930, Greg Lehey wrote:
>> On Wednesday, 25 August 1999 at 6:05:11 -0400, Thomas David Rivers wrote:
>>>> All the files under Tandem's NSK has mandatory l
th of whom explicitly stated that opening does not
block.
It had nothing to do with mandatory locking beyond that (quite
possibly flawed) interpretation.
> By your definiton of explicit, no. However, explicit locking is
> voluntary, just as advisory locking is voluntary, in terms of
> wh
th of whom explicitly stated that opening does not
block.
It had nothing to do with mandatory locking beyond that (quite
possibly flawed) interpretation.
> By your definiton of explicit, no. However, explicit locking is
> voluntary, just as advisory locking is voluntary, in terms of
> whethe
> I was assuming that mandatory locking, in the context of this
> discussion, does not mean automatic, forced exclusion on open, but
> rather explicit locks, applied by calls similar to those used for
> advisory locking, that are enforced by the kernel.
It's not mandatory, if
> I was assuming that mandatory locking, in the context of this
> discussion, does not mean automatic, forced exclusion on open, but
> rather explicit locks, applied by calls similar to those used for
> advisory locking, that are enforced by the kernel.
It's not mandatory, if
> Not to jump down your throat, or anything, but you seem to be
> perpetuating some incorrct assumptions about both effect and
> proposed implementation details, and they must be stomped. 8-).
I was assuming that mandatory locking, in the context of this
discussion, does not mean
> Not to jump down your throat, or anything, but you seem to be
> perpetuating some incorrct assumptions about both effect and
> proposed implementation details, and they must be stomped. 8-).
I was assuming that mandatory locking, in the context of this
discussion, does not mean
On Thu, Aug 26, 1999 at 09:09:33AM +0930, Greg Lehey wrote:
> On Wednesday, 25 August 1999 at 6:05:11 -0400, Thomas David Rivers wrote:
> >> All the files under Tandem's NSK has mandatory locking. The file cannot be
> >> opened if another process has it opened. some t
On Wednesday, 25 August 1999 at 6:05:11 -0400, Thomas David Rivers wrote:
>> All the files under Tandem's NSK has mandatory locking. The file cannot be
>> opened if another process has it opened. some thing like
>>
>> * if the file is opened for reading, any one c
On Thu, Aug 26, 1999 at 09:09:33AM +0930, Greg Lehey wrote:
> On Wednesday, 25 August 1999 at 6:05:11 -0400, Thomas David Rivers wrote:
> >> All the files under Tandem's NSK has mandatory locking. The file cannot be
> >> opened if another process has it opened. some t
On Wednesday, 25 August 1999 at 6:05:11 -0400, Thomas David Rivers wrote:
>> All the files under Tandem's NSK has mandatory locking. The file cannot be
>> opened if another process has it opened. some thing like
>>
>> * if the file is opened for reading, any one c
> The thing about well-intentioned but incorrect locking code is that
> it will appear to work fine, until it trips over the one code path
> where it forgets to lock some file that it should have locked. And
> even then, the code will "work" just fine, until multiple processes
> are accessing that
> [Cc's trimmed]
>
> On Wed, Aug 25, 1999 at 12:15:24AM -0600, Wes Peters wrote:
> > > >
> > > > How 'bout "anyone who can kill the process holding the lock?"
> > >
> > > + file owner ( + root ).
> >
> > Which processes can't root kill?
>
> Zombies? :)
Kill their parents. Eventually, you wi
> > All the files under Tandem's NSK has mandatory locking. The file cannot be
> > opened if another process has it opened. some thing like
> >
> > * if the file is opened for reading, any one can open it for
> > reading but opening for writing gives er
it takes to convince someone it really is useful.
>
> It should only take one, as long as the arguments made are not bogus.
>
> IMHO Greg made some very silly arguments (or at least used some very
> stupid examples) for mandatory locking and never answered my points
> regarding them.
zes via SMB an interface that has
to implement NetBIOS calls, and those, in turn, externalize via
the DOS INT 2A/2C mechanisms into the file I/O INTs, that SAMBA
has to support mandatory locking.
In effect, it is an API which externalizes much of the same types
of operations that implement LEASE ope
> The thing about well-intentioned but incorrect locking code is that
> it will appear to work fine, until it trips over the one code path
> where it forgets to lock some file that it should have locked. And
> even then, the code will "work" just fine, until multiple processes
> are accessing tha
> [Cc's trimmed]
>
> On Wed, Aug 25, 1999 at 12:15:24AM -0600, Wes Peters wrote:
> > > >
> > > > How 'bout "anyone who can kill the process holding the lock?"
> > >
> > > + file owner ( + root ).
> >
> > Which processes can't root kill?
>
> Zombies? :)
Kill their parents. Eventually, you w
> > All the files under Tandem's NSK has mandatory locking. The file cannot be
> > opened if another process has it opened. some thing like
> >
> > * if the file is opened for reading, any one can open it for
> > reading but opening for writing gives er
it takes to convince someone it really is useful.
>
> It should only take one, as long as the arguments made are not bogus.
>
> IMHO Greg made some very silly arguments (or at least used some very
> stupid examples) for mandatory locking and never answered my points
> regarding th
zes via SMB an interface that has
to implement NetBIOS calls, and those, in turn, externalize via
the DOS INT 2A/2C mechanisms into the file I/O INTs, that SAMBA
has to support mandatory locking.
In effect, it is an API which externalizes much of the same types
of operations that implement LEASE ope
Greg Lehey wrote:
>
> On Wednesday, 25 August 1999 at 0:11:23 -0600, Wes Peters wrote:
> > "Daniel C. Sobral" wrote:
> >>
> >> Christopher Masto wrote:
> >>>
> >>> I don't see the use for it.
> >>
> >> :-)
> >>
> >> The thing is SO obviously flawed, that I wonder how many marketoid
> >> drones it
Greg Lehey wrote:
>
> On Wednesday, 25 August 1999 at 0:11:23 -0600, Wes Peters wrote:
> > "Daniel C. Sobral" wrote:
> >>
> >> Christopher Masto wrote:
> >>>
> >>> I don't see the use for it.
> >>
> >> :-)
> >>
> >> The thing is SO obviously flawed, that I wonder how many marketoid
> >> drones i
On Wed, 25 Aug 1999, Tim Vanderhoek wrote:
:[Cc's trimmed]
:
:On Wed, Aug 25, 1999 at 12:15:24AM -0600, Wes Peters wrote:
:> > >
:> > > How 'bout "anyone who can kill the process holding the lock?"
:> >
:> > + file owner ( + root ).
:>
:> Which processes can't root kill?
:
:Zombies? :)
ps sho
[Cc's trimmed]
On Wed, Aug 25, 1999 at 12:15:24AM -0600, Wes Peters wrote:
> > >
> > > How 'bout "anyone who can kill the process holding the lock?"
> >
> > + file owner ( + root ).
>
> Which processes can't root kill?
Zombies? :)
> > Otherwise I would be able to lock ~wes/FreeBSDmarkers a
On Wed, 25 Aug 1999, Tim Vanderhoek wrote:
:[Cc's trimmed]
:
:On Wed, Aug 25, 1999 at 12:15:24AM -0600, Wes Peters wrote:
:> > >
:> > > How 'bout "anyone who can kill the process holding the lock?"
:> >
:> > + file owner ( + root ).
:>
:> Which processes can't root kill?
:
:Zombies? :)
ps sh
[Cc's trimmed]
On Wed, Aug 25, 1999 at 12:15:24AM -0600, Wes Peters wrote:
> > >
> > > How 'bout "anyone who can kill the process holding the lock?"
> >
> > + file owner ( + root ).
>
> Which processes can't root kill?
Zombies? :)
> > Otherwise I would be able to lock ~wes/FreeBSDmarkers
(or at least used some very
stupid examples) for mandatory locking and never answered my points
regarding them. (The arguments of some of the ones opposing mandatory
locking have been equally silly.)
I *do* agree that mandatory locking *can* be useful, but the
usefulness is not nearly as broad a
> All the files under Tandem's NSK has mandatory locking. The file cannot be
> opened if another process has it opened. some thing like
>
> * if the file is opened for reading, any one can open it for
> reading but opening for writing gives error
> * if the file
(or at least used some very
stupid examples) for mandatory locking and never answered my points
regarding them. (The arguments of some of the ones opposing mandatory
locking have been equally silly.)
I *do* agree that mandatory locking *can* be useful, but the
usefulness is not nearly as broad a
> All the files under Tandem's NSK has mandatory locking. The file cannot be
> opened if another process has it opened. some thing like
>
> * if the file is opened for reading, any one can open it for
> reading but opening for writing gives error
> * if the file
On Wednesday, 25 August 1999 at 0:11:23 -0600, Wes Peters wrote:
> "Daniel C. Sobral" wrote:
>>
>> Christopher Masto wrote:
>>>
>>> I don't see the use for it.
>>
>> :-)
>>
>> The thing is SO obviously flawed, that I wonder how many marketoid
>> drones it took to make sensible people think it is a
ting off the inevitable.
In fact, this confusion with Vinum is more historical than anything.
I started thinking "what tools are available for this as yet not
clearly defined task that will run in user mode and require
locking?". The obvious first question was "do we support read
(
Tim Vanderhoek wrote:
>
> On Tue, Aug 24, 1999 at 08:25:59AM -0600, Wes Peters wrote:
> > >
> > > I don't like restricting the breaking of mandatory locks to the
> > > superuser. It could be restricted to specific users (say file owner +
> > > root)...
> >
> > How 'bout "anyone who can kill the p
"Daniel C. Sobral" wrote:
>
> Christopher Masto wrote:
> >
> > I don't see the use for it.
>
> :-)
>
> The thing is SO obviously flawed, that I wonder how many marketoid
> drones it took to make sensible people think it is actually useful.
> :-)
And how many programmers with nearly (or more tha
Sean Eric Fagan wrote:
>
> The fact that Greg thinks it's necessary and desirable (and he has
> considerably more OS experience than a lot of the people who have decided it's
> a stupid idea) should alone say a lot for the idea.
I was waiting for someone else to bring up that point, because I migh
On Wednesday, 25 August 1999 at 0:11:23 -0600, Wes Peters wrote:
> "Daniel C. Sobral" wrote:
>>
>> Christopher Masto wrote:
>>>
>>> I don't see the use for it.
>>
>> :-)
>>
>> The thing is SO obviously flawed, that I wonder how many marketoid
>> drones it took to make sensible people think it is
In article <19990825113518.d83273.kithrup.freebsd.cvs-...@freebie.lemis.com>
you write:
>Correct. I lock a stripe at a time.
What people need to realize is that Greg is doing this locking in user mode.
As such, he has two real options:
1. Implement a vinum-specific ioctl that locks a region o
sion with Vinum is more historical than anything.
I started thinking "what tools are available for this as yet not
clearly defined task that will run in user mode and require
locking?". The obvious first question was "do we support read
(i.e. mandatory) locking?".
> Or does n
Tim Vanderhoek wrote:
>
> On Tue, Aug 24, 1999 at 08:25:59AM -0600, Wes Peters wrote:
> > >
> > > I don't like restricting the breaking of mandatory locks to the
> > > superuser. It could be restricted to specific users (say file owner +
> > > root)...
> >
> > How 'bout "anyone who can kill the
"Daniel C. Sobral" wrote:
>
> Christopher Masto wrote:
> >
> > I don't see the use for it.
>
> :-)
>
> The thing is SO obviously flawed, that I wonder how many marketoid
> drones it took to make sensible people think it is actually useful.
> :-)
And how many programmers with nearly (or more th
Sean Eric Fagan wrote:
>
> The fact that Greg thinks it's necessary and desirable (and he has
> considerably more OS experience than a lot of the people who have decided it's
> a stupid idea) should alone say a lot for the idea.
I was waiting for someone else to bring up that point, because I mig
In article <[EMAIL PROTECTED]> you write:
>Correct. I lock a stripe at a time.
What people need to realize is that Greg is doing this locking in user mode.
As such, he has two real options:
1. Implement a vinum-specific ioctl that locks a region of a file at the
device level, or
2.
>
> This isn't locking, it's access exclusion. It's also not correct for
> NSK.
what is the difference between locking and access exclusion? i was thinking
both are same (locking implies access exclusion). in other words, My idea of
mandatory locking is same as excl
>
> This isn't locking, it's access exclusion. It's also not correct for
> NSK.
what is the difference between locking and access exclusion? i was thinking
both are same (locking implies access exclusion). in other words, My idea of
mandatory locking is same as excl
On Wednesday, 25 August 1999 at 8:31:23 +0530, Biju Susmer wrote:
> All the files under Tandem's NSK has mandatory locking. The file cannot be
> opened if another process has it opened. some thing like
>
> * if the file is opened for reading, any one can open it for
>
All the files under Tandem's NSK has mandatory locking. The file cannot be
opened if another process has it opened. some thing like
* if the file is opened for reading, any one can open it for
reading but opening for writing gives error
* if the file is open for writing, it can
On Tuesday, 24 August 1999 at 22:41:15 -0400, Albert D. Cahalan wrote:
>
> It is clear to me that BSD won't do this. SysV and Linux have
> this feature. Linux runs everywhere that FreeBSD does and has
> better features too... so why run BSD at all?
I assume you're talking a
> > I think what people are missing here is that Vinum, when doing
> > software RAID, is implementing a type of namespace escape, only
> > it isn't a standard namespace escape.
>
> Interesting terminology. I think you've lost most people already.
I hope not. It's not that hard a concept. You c
On Wednesday, 25 August 1999 at 8:31:23 +0530, Biju Susmer wrote:
> All the files under Tandem's NSK has mandatory locking. The file cannot be
> opened if another process has it opened. some thing like
>
> * if the file is opened for reading, any one can open it for
>
On Wednesday, 25 August 1999 at 1:52:38 +, Terry Lambert wrote:
>>> I don't want to express an opinion about the need or otherwise
>>> for mandatory locking, but I would appreciate a teensy
>>> clarification of the problem domain:
>>>
>>> On
All the files under Tandem's NSK has mandatory locking. The file cannot be
opened if another process has it opened. some thing like
* if the file is opened for reading, any one can open it for
reading but opening for writing gives error
* if the file is open for writing, it can
> > I don't want to express an opinion about the need or otherwise
> > for mandatory locking, but I would appreciate a teensy
> > clarification of the problem domain:
> >
> > On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote:
> >> To w
On Tuesday, 24 August 1999 at 22:41:15 -0400, Albert D. Cahalan wrote:
>
> It is clear to me that BSD won't do this. SysV and Linux have
> this feature. Linux runs everywhere that FreeBSD does and has
> better features too... so why run BSD at all?
I assume you're talking a
On Tue, Aug 24, 1999 at 05:51:54PM -0400, Tim Vanderhoek wrote:
> >
> > How 'bout "anyone who can kill the process holding the lock?"
On further reflection, I'd go even further: anyone who can set the
lock can break the lock. Presumably if they know enough to explicitly
break the lock, then they
> > I think what people are missing here is that Vinum, when doing
> > software RAID, is implementing a type of namespace escape, only
> > it isn't a standard namespace escape.
>
> Interesting terminology. I think you've lost most people already.
I hope not. It's not that hard a concept. You
On Wednesday, 25 August 1999 at 1:52:38 +, Terry Lambert wrote:
>>> I don't want to express an opinion about the need or otherwise
>>> for mandatory locking, but I would appreciate a teensy
>>> clarification of the problem domain:
>>>
>>> On
> > I don't want to express an opinion about the need or otherwise
> > for mandatory locking, but I would appreciate a teensy
> > clarification of the problem domain:
> >
> > On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote:
> >> To w
On Tue, Aug 24, 1999 at 05:51:54PM -0400, Tim Vanderhoek wrote:
> >
> > How 'bout "anyone who can kill the process holding the lock?"
On further reflection, I'd go even further: anyone who can set the
lock can break the lock. Presumably if they know enough to explicitly
break the lock, then the
still stomp over User 1's data. No need to close
> and reopen the file.
>
> Yes, it's WRONG code. Correct code would aquire a lock before
> reading.
My understanding of "mandatory locking" means that a program that
completely ignores any locking at all, if it tries
On Tuesday, 24 August 1999 at 10:59:34 +1000, Andrew Reilly wrote:
> Hi Greg, hackers list,
>
> I don't want to express an opinion about the need or otherwise
> for mandatory locking, but I would appreciate a teensy
> clarification of the problem domain:
>
> On Mon,
still stomp over User 1's data. No need to close
> and reopen the file.
>
> Yes, it's WRONG code. Correct code would aquire a lock before
> reading.
My understanding of "mandatory locking" means that a program that
completely ignores any locking at all, if it tr
On Tuesday, 24 August 1999 at 10:59:34 +1000, Andrew Reilly wrote:
> Hi Greg, hackers list,
>
> I don't want to express an opinion about the need or otherwise
> for mandatory locking, but I would appreciate a teensy
> clarification of the problem domain:
>
> On Mon,
On Tue, Aug 24, 1999 at 08:25:59AM -0600, Wes Peters wrote:
> >
> > I don't like restricting the breaking of mandatory locks to the
> > superuser. It could be restricted to specific users (say file owner +
> > root)...
>
> How 'bout "anyone who can kill the process holding the lock?"
+ file ow
On Tue, Aug 24, 1999 at 08:25:59AM -0600, Wes Peters wrote:
> >
> > I don't like restricting the breaking of mandatory locks to the
> > superuser. It could be restricted to specific users (say file owner +
> > root)...
>
> How 'bout "anyone who can kill the process holding the lock?"
+ file o
On Tue, Aug 24, 1999 at 11:33:33AM -0400, Chuck Robey wrote:
> > Yes, it's WRONG code. Correct code would aquire a lock before
> > reading.
>
> My understanding of "mandatory locking" means that a program that
> completely ignores any locking at all, if it
At 11:17 AM -0400 8/24/99, Christopher Masto wrote:
I'm sure there are situations where mandatory locking accomplishes
something useful. Are they worth it? (I don't claim to know; if
the problems I thought I pointed out don't really exist, good.)
More seriously than just b
At 11:27 PM -0400 8/23/99, Christopher Masto wrote:
On Mon, Aug 23, 1999 at 11:16:21PM -0400, Chuck Robey wrote:
> What has that code you show above got to do with mandatory locking?
> You completely missed the explicit locking calls that you have to make,
> to get and release the locks
On Tue, Aug 24, 1999 at 11:33:33AM -0400, Chuck Robey wrote:
> > Yes, it's WRONG code. Correct code would aquire a lock before
> > reading.
>
> My understanding of "mandatory locking" means that a program that
> completely ignores any locking at all, if it
At 11:17 AM -0400 8/24/99, Christopher Masto wrote:
>I'm sure there are situations where mandatory locking accomplishes
>something useful. Are they worth it? (I don't claim to know; if
>the problems I thought I pointed out don't really exist, good.)
>
>More seriou
s a mutex on a part/whole file.
Mandatory locking enables a process to ensure that its transaction is
safe from interference. Interference that can come from a correctly
running program writing at the wrong time (but not using the locks --
maybe you don't have source for it either).
What happens i
s a mutex on a part/whole file.
Mandatory locking enables a process to ensure that its transaction is
safe from interference. Interference that can come from a correctly
running program writing at the wrong time (but not using the locks --
maybe you don't have source for it either).
What happens i
Chuck Robey wrote:
>
> On Mon, 23 Aug 1999, Christopher Masto wrote:
>
> > Bleah.. I can't count the number of times I've seen idiotic code like:
> >
> > open file
> > read data
> > close file
> > open file for write
> > write da
Christopher Masto wrote:
>
> Exactly. You said that mandatory locking means that user A's correct
> use of locking means that user B doesn't have to be careful. That's
> not the case, since A can step in between B's read and write. A's
> mandatory loc
is that
> it will appear to work fine, until it trips over the one code path
> where it forgets to lock some file that it should have locked. And
> even then, the code will "work" just fine, until multiple processes
> are accessing that file at the same time.
A well-intentione
At 11:27 PM -0400 8/23/99, Christopher Masto wrote:
>On Mon, Aug 23, 1999 at 11:16:21PM -0400, Chuck Robey wrote:
> > What has that code you show above got to do with mandatory locking?
> > You completely missed the explicit locking calls that you have to make,
> > to get
On Tue, Aug 24, 1999 at 08:35:25AM -0600, Wes Peters wrote:
> You've got this so wrong, perhaps you should just go find a System V man
> page and read about mandatory locking before embarassing yourself any-
> more.
First of all, when was it decided that we were all talking abou
visory locking.
You've got this so wrong, perhaps you should just go find a System V man
page and read about mandatory locking before embarassing yourself any-
more.
Locking will only block if another process is holding an overlapping lock.
opening won't block due to mandatory locking.
Christopher Masto wrote:
>
> > The thing about well-intentioned but incorrect locking code is that
> > it will appear to work fine, until it trips over the one code path
> > where it forgets to lock some file that it should have locked. And
> > even then, the code will "work" just fine, until mul
Tim Vanderhoek wrote:
>
> On Mon, Aug 23, 1999 at 10:12:38PM +0200, Mark Murray wrote:
> >
> > In process-space, this is the kernel. In file-space, this should
> > be root. Processes that require mandatory locking must revoke
> > superuser before attempting locks.
Christopher Masto wrote:
>
> Exactly. You said that mandatory locking means that user A's correct
> use of locking means that user B doesn't have to be careful. That's
> not the case, since A can step in between B's read and write. A's
> mandatory loc
Chuck Robey wrote:
>
> On Mon, 23 Aug 1999, Christopher Masto wrote:
>
> > Bleah.. I can't count the number of times I've seen idiotic code like:
> >
> > open file
> > read data
> > close file
> > open file for write
> > write da
is that
> it will appear to work fine, until it trips over the one code path
> where it forgets to lock some file that it should have locked. And
> even then, the code will "work" just fine, until multiple processes
> are accessing that file at the same time.
A well-intenti
On Tue, Aug 24, 1999 at 08:35:25AM -0600, Wes Peters wrote:
> You've got this so wrong, perhaps you should just go find a System V man
> page and read about mandatory locking before embarassing yourself any-
> more.
First of all, when was it decided that we were all talking abou
Tim Vanderhoek wrote:
>
> On Mon, Aug 23, 1999 at 10:12:38PM +0200, Mark Murray wrote:
> >
> > In process-space, this is the kernel. In file-space, this should
> > be root. Processes that require mandatory locking must revoke
> > superuser before attempting locks.
Christopher Masto wrote:
>
> > The thing about well-intentioned but incorrect locking code is that
> > it will appear to work fine, until it trips over the one code path
> > where it forgets to lock some file that it should have locked. And
> > even then, the code will "work" just fine, until mu
sing advisory locking.
You've got this so wrong, perhaps you should just go find a System V man
page and read about mandatory locking before embarassing yourself any-
more.
Locking will only block if another process is holding an overlapping lock.
opening won't block due to mandatory locking
ly end up with a broken mailbox.
>>
>> what you do is this:
>> lockf -k $mailfile cat ${mailtmp} >> $mailfile
>
> Which doesn't support Greg's arguments for mandatory locking, as
> you're now doing locking in both programs.
Well, it doesn't supp
sendmail delivers new mail
> > sendmail unlocks /var/mail/grog
> > cat writes the rest of oldmail to /var/mail/grog
> >
> > You'll still probably end up with a broken mailbox.
>
> what you do is this:
> lockf -k $mailfile cat ${mailtmp} >> $mai
orks, but it's playing with fire: if sendmail is delivering a
> > message at the same time, it won't see me, and my cat doesn't get a
> > lock beforehand, so both an incoming message and part of my mail
> > folder could end up getting written to the same location.
ly end up with a broken mailbox.
>>
>> what you do is this:
>> lockf -k $mailfile cat ${mailtmp} >> $mailfile
>
> Which doesn't support Greg's arguments for mandatory locking, as
> you're now doing locking in both programs.
Well, it doesn't supp
sendmail delivers new mail
> > sendmail unlocks /var/mail/grog
> > cat writes the rest of oldmail to /var/mail/grog
> >
> > You'll still probably end up with a broken mailbox.
>
> what you do is this:
> lockf -k $mailfile cat ${mailtmp} >> $mai
t won't see me, and my cat doesn't get a
> lock beforehand, so both an incoming message and part of my mail
> folder could end up getting written to the same location. With
> mandatory locking, it would work, transparently.
Certainly not with range-locking rather than file-lo
t; That works, but it's playing with fire: if sendmail is delivering a
> > message at the same time, it won't see me, and my cat doesn't get a
> > lock beforehand, so both an incoming message and part of my mail
> > folder could end up getting written to the same location.
chu...@picnic.mat.net (Chuck Robey) writes:
> On 23 Aug 1999, Ville-Pertti Keinonen wrote:
> > And even without otherwise incorrect behavior, if you have a program
> > that doesn't use any locking and another one that uses mandatory
> > locking to prevent races with th
e, it won't see me, and my cat doesn't get a
> lock beforehand, so both an incoming message and part of my mail
> folder could end up getting written to the same location. With
> mandatory locking, it would work, transparently.
Certainly not with range-locking rather than file-lo
[EMAIL PROTECTED] (Chuck Robey) writes:
> On 23 Aug 1999, Ville-Pertti Keinonen wrote:
> > And even without otherwise incorrect behavior, if you have a program
> > that doesn't use any locking and another one that uses mandatory
> > locking to prevent races with th
1 - 100 of 180 matches
Mail list logo
