I was too hasty with: d1fe6ff xfs_quota: remove extra 30 seconds from time limit reporting The point of that extra 30s, turns out, was to allow the user to set a limit, query it, and get back what they just set, if it is set to more than a day. Without it, if we set a grace period to i.e. 3 days, and query it 1 second later, the rounding in the time_to_string function returns "2 days" not "3 days" as it did before, because we are at 2 days 23:59:59 and it essentially applies a floor() for brevity. I guess this was confusing. (I've run into this same conundrum on my stove digital timer; if you set it to 10m, it blinks "10" at you twice so that you know what you set, then quickly flips to 9 as it counts down). In some cases, however (and this is the case that prompted the prior patch), we display a full "XYZ days hh:mm:ss" - we do this if the verbose flag is set, or if the timer is less than one day. In these cases, we should not add the 30s, because we are showing full time resolution to the user. Reported-by: Zorro Lang <zlang@xxxxxxxxxx> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> --- (I don't like my patch title, but I can't think of a better one) diff --git a/quota/util.c b/quota/util.c index 7c43fbd..5e988f9 100644 --- a/quota/util.c +++ b/quota/util.c @@ -43,6 +43,18 @@ time_to_string( timer = MAX(origin - now, 0); } + /* + * If we are in verbose mode, or if less than a day remains, we + * will show "X days hh:mm:ss" so the user knows the exact timer status. + * + * Otherwise, we round down to the nearest day - so we add 30s here + * such that setting and reporting a limit in rapid succession will + * show the limit which was just set, rather than immediately reporting + * one day less. + */ + if ((timer > SECONDS_IN_A_DAY) && !(flags & VERBOSE_FLAG)) + timer += 30; /* seconds */ + days = timer / SECONDS_IN_A_DAY; if (days) timer %= SECONDS_IN_A_DAY; _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
