bug#53033: date has multiple "first saturday"s?
From coreutils 9.0 (note the difference between the "second" and "third" saturdays): $ src/date --debug -d "first saturday" date: parsed day part: next/first Sat (day ordinal=1 number=6) date: input timezone: system default date: warning: using midnight as starting time: 00:00:00 date: new start date: 'next/first Sat' is '(Y-M-D) 2022-01-08 00:00:00' date: starting date/time: '(Y-M-D) 2022-01-08 00:00:00' date: '(Y-M-D) 2022-01-08 00:00:00' = 1641628800 epoch-seconds date: timezone: system default date: final: 1641628800.0 (epoch-seconds) date: final: (Y-M-D) 2022-01-08 08:00:00 (UTC) date: final: (Y-M-D) 2022-01-08 00:00:00 (UTC-08) src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’ Sat Jan 8 00:00:00 PST 2022 $ src/date --debug -d "second saturday" date: parsed relative part: +1 seconds date: parsed day part: Sat (day ordinal=0 number=6) date: input timezone: system default date: warning: using midnight as starting time: 00:00:00 date: new start date: 'Sat' is '(Y-M-D) 2022-01-08 00:00:00' date: starting date/time: '(Y-M-D) 2022-01-08 00:00:00' date: '(Y-M-D) 2022-01-08 00:00:00' = 1641628800 epoch-seconds date: after time adjustment (+0 hours, +0 minutes, +1 seconds, +0 ns), date: new time = 1641628801 epoch-seconds date: timezone: system default date: final: 1641628801.0 (epoch-seconds) date: final: (Y-M-D) 2022-01-08 08:00:01 (UTC) date: final: (Y-M-D) 2022-01-08 00:00:01 (UTC-08) src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’ Sat Jan 8 00:00:01 PST 2022 $ src/date --debug -d "third saturday" date: parsed day part: third Sat (day ordinal=3 number=6) date: input timezone: system default date: warning: using midnight as starting time: 00:00:00 date: new start date: 'third Sat' is '(Y-M-D) 2022-01-22 00:00:00' date: starting date/time: '(Y-M-D) 2022-01-22 00:00:00' date: '(Y-M-D) 2022-01-22 00:00:00' = 1642838400 epoch-seconds date: timezone: system default date: final: 1642838400.0 (epoch-seconds) date: final: (Y-M-D) 2022-01-22 08:00:00 (UTC) date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC-08) src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’ Sat Jan 22 00:00:00 PST 2022 -- Darryl -Original Message- From: Andreas Schwab Sent: Wednesday, January 5, 2022 2:10 PM To: Darryl Okahata via GNU coreutils Bug Reports Cc: 53...@debbugs.gnu.org; Darryl Okahata Subject: Re: bug#53033: date has multiple "first saturday"s? On Jan 05 2022, Darryl Okahata via GNU coreutils Bug Reports wrote: > $ date -d "first saturday" > Sat Jan 8 00:00:00 PST 2022 > > Unless there is some weird definition of "first Saturday", shouldn't > this be the 1st (New Year's Day)? Try date --debug. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
bug#53037: df/total-verify fail with cephfs
On 1/5/22 15:25, Dylan Simon wrote: Hrm, no, with this patch it still fails, but differently (sorry so many filesystems): OK, then perhaps someone with a bit more free time will have to look at it - unless you can propose a patch that passed "make check".
bug#53037: df/total-verify fail with cephfs
>From Paul Eggert , Wed, Jan 05, 2022 at 03:07:42PM -0800:
> On 1/5/22 14:11, Dylan Simon wrote:
> > Then it will look like this (I'm inferring, haven't actually tried it):
>
> I'm still not quite following, but does the attached patch address the
> problem?
Hrm, no, with this patch it still fails, but differently (sorry so many
filesystems):
FilesystemInodes IUsed IFree IUse% Mounted on
devtmpfs65968964743 659682211% /dev
tmpfs 65988311 1250 659870611% /run
/dev/sda1 20971520 529832 204416883% /
tmpfs 65988311 4688 659836231% /dev/shm
tmpfs 65988311 14 659882971% /sys/fs/cgroup
/dev/sda3 212927488 21130 2129063581% /var
/dev/sdb1 234424320 36 2344242841% /tmp
ceph 901242617 - - - /mnt/ceph
home 26000 121454853 138545147 47% /mnt/home
bright 26214400 191667827047618 74% /cm/shared
tmpfs 65988311 1 659883101% /run/user/0
tmpfs 65988311 1 659883101% /run/user/1135
tmpfs 65988311 1 659883101% /run/user/1000
total 141179331 -934077896 1075257227 - -
2117679175 != 141179331 at check-df line 14, <> line 15.
In case it's helpful, here's the statfs:
statfs("/mnt/ceph", {f_type=FUSE_SUPER_MAGIC, f_bsize=4194304,
f_blocks=7243311664, f_bfree=1707119480, f_bavail=1707119480,
f_files=901242617, f_ffree=18446744073709551615, f_fsid={val=[0, 0]},
f_namelen=255, f_frsize=4194304, f_flags=ST_VALID|ST_RELATIME}) = 0
(This is a coreutils 8.32 build by the way but I'm happy to try 9.0 or git if
there's reason to think that will help.)
bug#53037: df/total-verify fail with cephfs
On 1/5/22 14:11, Dylan Simon wrote:
Then it will look like this (I'm inferring, haven't actually tried it):
I'm still not quite following, but does the attached patch address the
problem?diff --git a/src/df.c b/src/df.c
index b803fc73b..8a0293ca9 100644
--- a/src/df.c
+++ b/src/df.c
@@ -127,6 +127,7 @@ static bool print_grand_total;
/* Grand total data. */
static struct fs_usage grand_fsu;
+static bool grand_fsu_fsu_files_top_bit_set;
/* Display modes. */
enum
@@ -993,8 +994,11 @@ get_field_values (struct field_values_t *bv,
static void
add_to_grand_total (struct field_values_t *bv, struct field_values_t *iv)
{
- if (known_value (iv->total))
-grand_fsu.fsu_files += iv->total;
+ if (known_value (iv->total) && known_value (iv->available_to_root))
+add_uint_with_neg_flag (_fsu.fsu_files,
+_fsu_fsu_files_top_bit_set,
+iv->total - iv->available_to_root,
+iv->total < iv->available_to_root);
if (known_value (iv->available))
grand_fsu.fsu_ffree += iv->available;
@@ -1860,6 +1864,9 @@ main (int argc, char **argv)
NULL, NULL, NULL, false, false, _fsu, false);
print_table ();
+
+ if (print_grand_total & grand_fsu_fsu_files_top_bit_set)
+die (EXIT_FAILURE, 0, "iused < 0");
}
else
{
bug#53033: date has multiple "first saturday"s?
On Jan 05 2022, Darryl Okahata via GNU coreutils Bug Reports wrote: > $ date -d "first saturday" > Sat Jan 8 00:00:00 PST 2022 > > Unless there is some weird definition of "first Saturday", shouldn't this be > the 1st (New Year's Day)? Try date --debug. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
bug#53037: df/total-verify fail with cephfs
>From Paul Eggert , Wed, Jan 05, 2022 at 01:05:03PM -0800:
> On 1/5/22 11:27, Dylan Simon wrote:
> > Only adding rows with all known values
> > might make sense but would still break the test (wrong total total instead):
> >
> >if (known_value (iv->total) && known_value (iv->available)) {
> > grand_fsu.fsu_files += iv->total;
> > grand_fsu.fsu_ffree += iv->available;
> >}
>
> Sorry, I'm not quite following. If you make the above change, what will the
> output look like instead? And how will that break the test?
Then it will look like this (I'm inferring, haven't actually tried it):
FilesystemInodes IUsedIFree IUse% Mounted on
/dev/sda1 20971520529832 204416883% /
ceph 901006598 -- - /mnt/ceph
total 20971520529832 204416883% -
That is, the ceph line will just be excluded completely from the total. Now
the used and free lines add up correctly, but total Inodes does not.
bug#53037: df/total-verify fail with cephfs
On 1/5/22 11:27, Dylan Simon wrote:
Only adding rows with all known values
might make sense but would still break the test (wrong total total instead):
if (known_value (iv->total) && known_value (iv->available)) {
grand_fsu.fsu_files += iv->total;
grand_fsu.fsu_ffree += iv->available;
}
Sorry, I'm not quite following. If you make the above change, what will
the output look like instead? And how will that break the test?
bug#53025: Encouragement to go back to *dis*abled quotation marks in ls output as *default* behavior
On 1/5/22 00:44, Joerg M. Sigle wrote: "When this many people consider a thing a bug, then it's a bug whether maintainers disagree or not." By that standard it'll be a bug no matter what the maintainers do, since feelings are strong on both sides of the issue. So by this reasoning, maintainers might as well do nothing. In the meantime you can avoid the issue yourself by using this: alias ls="ls -N" in your .profile or whatever.
bug#53037: df/total-verify fail with cephfs
We have a filesystem that reports statfs f_files = nfiles, f_ffree = -1
(UINTMAX_MAX). (See rationale https://github.com/ceph/ceph/pull/36127)
Unfortunately this breaks df -i --total and in particular the df/total-verify
test fails. Example output:
> df -i --total / /mnt/ceph
FilesystemInodes IUsedIFree IUse% Mounted on
/dev/sda1 20971520529832 204416883% /
ceph 901006598 -- - /mnt/ceph
total 921978118 901536430 20441688 98% -
You can see that the total used is clearly not the computed total. I think
this is because the individual rows use this logic for used:
iv->used = UINTMAX_MAX;
if (known_value (iv->total) && known_value (iv->available_to_root))
iv->used = iv->total - iv->available_to_root;
while add_to_grand_total does them separately:
if (known_value (iv->total))
grand_fsu.fsu_files += iv->total;
if (known_value (iv->available))
grand_fsu.fsu_ffree += iv->available;
So the ceph line gets added to total but not available, and as a result, the
used computation of fsu_files - fsu_ffree = root.total + ceph.total -
root.available. Maybe this is sensible but it's not what the test expects.
I can't think of a way to solve this that makes the test pass, aside from
collecting a grand_used total as well. Only adding rows with all known values
might make sense but would still break the test (wrong total total instead):
if (known_value (iv->total) && known_value (iv->available)) {
grand_fsu.fsu_files += iv->total;
grand_fsu.fsu_ffree += iv->available;
}
bug#53033: date has multiple "first saturday"s?
(This has been verified to occur with 9.0.) $ date -d "first saturday" Sat Jan 8 00:00:00 PST 2022 Unless there is some weird definition of "first Saturday", shouldn't this be the 1st (New Year's Day)? Also, I ran this last week (I think on the 29th or the 30th), and it did properly report the 1st. Now that it's after the 1st, it's reporting the 8th. Side note: I'm happy that it reported Jan 1st as the "first Saturday" even though the date was still in December, but is there a way of getting the "first Saturday" for an arbitrary year/month? All my attempts just get the "invalid date" error. -- Darryl
bug#53025: Encouragement to go back to *dis*abled quotation marks in ls output as *default* behavior
On 05/01/2022 08:44, Joerg M. Sigle wrote: Dear coreutils developers Thank you very much for your efferts in trying to provide and maintain fine tools that help millions or billions of users every day. I'm one who appreciates that (and I try to do something similar as well). Still, sometimes there have been changes introduced over the years, that may have been well intended, but still do more harm than good, even if not visible to everyone at first glance. Introduction of quotation marks placed selectively around ls output containing spaces is an example for that. I'd like to encourage you to make this behaviour an option again, and put the default setting back to leaving these quotation marks away. Whoever wants them, can activate them - and who doesn't, won't be bothered by an inconsistent and somewhat annoying behavior that disrupts the visual processing of every single ls output where it becomes apparent - and requires the addition of an option line for every single existing(!) .bashrc file on systems where the "new" behaviour is not desired. And, given the change was introduced in 2016, and re-introduced in 2019, and annoyance is still caused in 2021 - well, whenever it has been fixed in existing systems, the problem still turns up in each and every newly set up system since then, in a delayed manner because naturally ls output with spaces is not the first thing that will appear, and therefore requires a lookup of its cause and remedy, and then the manual addition of fixes to each already existing user account set up until then. upstream has been consistent in maintaining the behavior since it was introduced. As somebody put it on publicly available pages: "When this many people consider a thing a bug, then it's a bug whether maintainers disagree or not." Quoted from: https://unix.stackexchange.com/questions/258679/why-is-ls-suddenly-wrapping-items-with-spaces-in-single-quotes/262162#262162 The bigger problem is, that it's not only ls which is affected like that. Similar changes, instead, occur in more and more places - in browsers, in the X11 environment (now even losing it's network transparency etc.), in the design of GUIs with inconsistant apprance and unrecognizable operating elements and so on. It's like if somebody has a bad idea, they're not held back by traditions or established standards or knowledgeable people around them any more - but on the contrary, that bad idea is immediately implemented, distributed, and then: even copied over and over by other people who think things must constantly be "renewed" even if the existing version was perfect and simple, and "new" usually means "more complex" and "obviously worse". Anyway. Thank you very much for consideration of this message, including its philosophical background, and kind regards! Reasoning for the default behavior is detailed at: https://www.gnu.org/software/coreutils/quotes.html thanks, Pádraig.
bug#53025: Encouragement to go back to *dis*abled quotation marks in ls output as *default* behavior
Dear coreutils developers Thank you very much for your efferts in trying to provide and maintain fine tools that help millions or billions of users every day. I'm one who appreciates that (and I try to do something similar as well). Still, sometimes there have been changes introduced over the years, that may have been well intended, but still do more harm than good, even if not visible to everyone at first glance. Introduction of quotation marks placed selectively around ls output containing spaces is an example for that. I'd like to encourage you to make this behaviour an option again, and put the default setting back to leaving these quotation marks away. Whoever wants them, can activate them - and who doesn't, won't be bothered by an inconsistent and somewhat annoying behavior that disrupts the visual processing of every single ls output where it becomes apparent - and requires the addition of an option line for every single existing(!) .bashrc file on systems where the "new" behaviour is not desired. And, given the change was introduced in 2016, and re-introduced in 2019, and annoyance is still caused in 2021 - well, whenever it has been fixed in existing systems, the problem still turns up in each and every newly set up system since then, in a delayed manner because naturally ls output with spaces is not the first thing that will appear, and therefore requires a lookup of its cause and remedy, and then the manual addition of fixes to each already existing user account set up until then. As somebody put it on publicly available pages: "When this many people consider a thing a bug, then it's a bug whether maintainers disagree or not." Quoted from: https://unix.stackexchange.com/questions/258679/why-is-ls-suddenly-wrapping-items-with-spaces-in-single-quotes/262162#262162 The bigger problem is, that it's not only ls which is affected like that. Similar changes, instead, occur in more and more places - in browsers, in the X11 environment (now even losing it's network transparency etc.), in the design of GUIs with inconsistant apprance and unrecognizable operating elements and so on. It's like if somebody has a bad idea, they're not held back by traditions or established standards or knowledgeable people around them any more - but on the contrary, that bad idea is immediately implemented, distributed, and then: even copied over and over by other people who think things must constantly be "renewed" even if the existing version was perfect and simple, and "new" usually means "more complex" and "obviously worse". Anyway. Thank you very much for consideration of this message, including its philosophical background, and kind regards! Joerg -- --- Dr. med. Jörg M. Sigle +41 76 276 86 94 http://www.ql-recorder.com +41 32 510 23 46 http://www.jsigle.com +49 176 96 43 54 13
