[PATCH] Add additional error handling to safe_rename().

2018-08-26 Thread Kevin J. McCarthy
001 From: Kevin McCarthy Date: Sun, 26 Aug 2018 18:43:20 -0700 Subject: [PATCH] Add additional error handling to safe_rename(). It is apparently possible for link() to return an error but the link to still be created. Add a double check for that case. If the files match, unlink the src and

Re: [PATCH] Add additional error handling to safe_rename().

2018-08-28 Thread Derek Martin
> From f0faf6cf205e0b96c2fb93ea12393458843aa485 Mon Sep 17 00:00:00 2001 > From: Kevin McCarthy > Date: Sun, 26 Aug 2018 18:43:20 -0700 > Subject: [PATCH] Add additional error handling to safe_rename(). > > It is apparently possible for link() to return an error but the

Re: [PATCH] Add additional error handling to safe_rename().

2018-08-28 Thread Kevin J. McCarthy
On Tue, Aug 28, 2018 at 03:27:51PM -0500, Derek Martin wrote: > On Sun, Aug 26, 2018 at 06:48:46PM -0700, Kevin J. McCarthy wrote: > > Here's a first try at a patch to check for the historically documented > > "link() returning -1 but succeeding" case for NFS. > > This seems fine. Thank you for t

Re: [PATCH] Add additional error handling to safe_rename().

2018-08-29 Thread Derek Martin
On Tue, Aug 28, 2018 at 06:08:46PM -0700, Kevin J. McCarthy wrote: > > Though, it seems it leaves in the stat comparison if > > link() succeeds, which is superfluous (could cause needless > > performance hit on slow networked filesystems), and violates KISS and > > "Don't write code you don't need"

Re: [PATCH] Add additional error handling to safe_rename().

2018-08-29 Thread Kevin J. McCarthy
On Wed, Aug 29, 2018 at 12:16:14PM -0500, Derek Martin wrote: > So, I think the post-success stat() calls should should come out, and > I wouldn't bother using #if to remove it. I think it's clearly just a > bad idea to do that check there, and we should remove any trace of it > so that no one is