On Sun, Apr 06, 2014 at 11:54:59PM +0200, Michael Haggerty wrote:
> > I didn't reproduce it experimentally, though. We should be able to just
> >
> > lk->owner = 0;
> >
> > before the initial strcpy to fix it, I would think.
>
> I think that using the owner field to avoid this problem is a
On 04/01/2014 10:16 PM, Jeff King wrote:
> On Tue, Apr 01, 2014 at 05:58:15PM +0200, Michael Haggerty wrote:
>
>> diff --git a/lockfile.c b/lockfile.c
>> index e679e4c..c989f6c 100644
>> --- a/lockfile.c
>> +++ b/lockfile.c
>> @@ -130,6 +130,22 @@ static int lock_file(struct lock_file *lk, const c
Jeff King writes:
> So for a moment, lk->filename contains the name of the valuable file we
> are locking. If we get a signal at that moment, do we accidentally
> delete it in remove_lock_file?
>
> I think the answer is "no", because we check lk->owner before deleting,
> which will not match our
On Tue, Apr 01, 2014 at 05:58:15PM +0200, Michael Haggerty wrote:
> diff --git a/lockfile.c b/lockfile.c
> index e679e4c..c989f6c 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -130,6 +130,22 @@ static int lock_file(struct lock_file *lk, const char
> *path, int flags)
>*/
> stati
4 matches
Mail list logo
