On Mon, Mar 05, 2018 at 05:49:26PM -0500, Steve Dickson wrote: > > > On 03/05/2018 04:53 PM, J. Bruce Fields wrote: > > On Mon, Mar 05, 2018 at 10:54:20AM -0500, Steve Dickson wrote: > >> Signed-off-by: Steve Dickson <steved@xxxxxxxxxx> > >> --- > >> support/nfs/nfs_mntent.c | 3 ++- > >> utils/blkmapd/device-discovery.c | 6 ++++-- > >> utils/mount/network.c | 8 ++++++-- > >> utils/nfsd/nfssvc.c | 5 +++-- > >> utils/statd/statd.c | 3 ++- > >> 5 files changed, 17 insertions(+), 8 deletions(-) > >> > >> diff --git a/support/nfs/nfs_mntent.c b/support/nfs/nfs_mntent.c > >> index a2118a2..c60988a 100644 > >> --- a/support/nfs/nfs_mntent.c > >> +++ b/support/nfs/nfs_mntent.c > >> @@ -150,7 +150,8 @@ nfs_addmntent (mntFILE *mfp, struct mntent *mnt) { > >> res = fflush(mfp->mntent_fp); > >> if (res < 0) > >> /* Avoid leaving a corrupt mtab file */ > >> - ftruncate(fileno(mfp->mntent_fp), length); > >> + if (ftruncate(fileno(mfp->mntent_fp), length)) > >> + {/* ignore return value */}; > > > > Might be worth a log warning? > Yes... I thought about that. But I could not think of any meaningful > log that would help diagnose the problem... The ftruncate() is basically > cleanly up a mess.. > > Maybe log an error message from the fflush()? Yeah, and I admit maybe it's not worth anything specifically by the time the ftruncate also fails. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html