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 bit
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 char
Jeff King p...@peff.net 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
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)
*/
static const
4 matches
Mail list logo