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
