bug#70298: uname -i returns unknown since fedora 38

[Bernhard Voelker]

On 4/9/24 2:21 PM, Pádraig Brady wrote:

Thanks for looking at this.
 From the Fedora side, they dropped a Fedora specific patch for Fedora 38.

https://bugzilla.redhat.com/show_bug.cgi?id=548834
https://bugzilla.redhat.com/show_bug.cgi?id=2208048


FWIW: OpenSUSE still has that patch which was kept in sync with Fedora for 
years:

  
https://build.opensuse.org/projects/openSUSE:Factory/packages/coreutils/files/coreutils-sysinfo.patch?expand=1

I have no strong opinion about it, but I guess some (build?) scripts rely on 
this.

Have a nice day,
Berny

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

[Bernhard Voelker]

On 3/22/24 11:22, Karel Zak wrote:
> On Wed, Mar 20, 2024 at 11:53:05PM +0100, Bernhard Voelker wrote:>> On 
userland OTOH, we have broader choice.
>> Karel did his choice in util-linux for exch(1), and coreutils could expose
>> the same functionality.
>>
>> For other feature requests, we were much more reluctant in coreutils ... for
>> good reasons: feature bloat, maintainability, etc.
>>
>> So I'm asking myself what is different this time?
>> - The feature already exists -> util-linux.
>
> Note that we can move exch(1) from util-linux to coreutils if, at the
> end of the brainstorming session, the conclusion will be that mv(1) is
> a bad choice :-)

I'd be for that as well, because ...

>> I'm currently only 20:80 for adding it to mv(1).
>
> I think the functionality will be lost in the mv(1) for many users.

... that's a fair point.

The code for the functionality is in copy.c, so - as with mv.c/cp.c/install.c -
we could have a exch.c using just that part, and thus expose a clearer interface
to the users.

Have a nice day,
Berny

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

[Bernhard Voelker]

On 3/23/24 02:44, Paul Eggert wrote:

I installed the attached patches to do the above. (Basically, the
problem was that my earlier patches were too ambitious; these patches
scale things back to avoid some optimizations so that mv --exchange is
more like ordinary mv.)

The first patch simplifies the code (and fixes a diagnostic to be more
useful) without otherwise changing behavior; it's more of a refactoring.
The second patch does the real work.


Thanks.

We should put adding more tests on our TODO list still.

Have a nice day,
Berny

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

[Bernhard Voelker]

On 3/21/24 00:56, Paul Eggert wrote:

On 3/20/24 15:53, Bernhard Voelker wrote:
Yes, that's the expected behavior for this contrived case. Just as one
would get odd behavior if one did the same thing without --exchange.


There's another which is not consistent with/without --exchange:

  $ src/mv -v a a
  src/mv: 'a' and 'a' are the same file

  $ src/mv -v --exchange a a
  renamed 'a' -> 'a'

RENAME_EXCHANGE is allowed (but useless?) for 1 file.

BTW: shouldn't the -v diagnostic better say "exchanged 'a' <-> 'a'"
because that's what happened?


    - not sure if exchange works well together with -f.


What problems do you see there?


it's up to the tests to proof that.


why does exchange not work to exchange a regular with a
directory file?


It works. I don't see a problem there.

$ touch a
$ mkdir d
$ ./mv -T --exchange a d
$ ls -ld a d
drwxr-xr-x. 2 eggert eggert 4096 Mar 20 16:52 a
-rw-r--r--. 1 eggert eggert0 Mar 20 16:52 d


indeed, it works.  It seems my test was wrong, sorry.


Finally, the test cases are very sparse:


Feel free to add some. :-)


Unfortunately, I cannot currently spend as much time as I'd love to.

It seems that -i is skipped:

  $ src/mv -iv --exchange a b
  renamed 'a' -> 'b'

As far as I know Padraig would like to do the next release very soon,
so I would recommend to not hurrying this one into it, and instead
ironing all out after the release.

Have a nice day,
Berny

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

[Bernhard Voelker]

On 3/20/24 21:56, Paul Eggert wrote:

On 3/20/24 12:43, Bernhard Voelker wrote:


This stems from the fact that although mv(1) is a userland frontend
for renameat(2), the user interface is different:
while renameat(2) deals exactly with 2 operands, mv(1) has always
been able to work on more arguments.


Yes, that's mv's original sin, which we cannot realistically change now.


I wouldn't go that far that it was a sin.  It's useful and people got
used to it without having to think about it.


I have the gut feeling that we didn't think through all cases,
and that some might be surprising, e.g.:

    $ mkdir d; echo 1 > a; echo 2 > d/a
    $ src/mv --exchange a a a a d/a

versus

    $ src/mv --exchange a a a a d/a


I don't understand the word "versus" here, as the two examples look the
same to me.


sorry, I messed the example up.

  $ echo 1 > a
  $ mkdir d
  $ echo 2 > d/a
  $ src/mv -v --exchange a a a d
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  $ cat a
  2
  $ src/mv -v --exchange a a a d
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  $ cat a
  1
  $ src/mv -v --exchange a a a a d
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  renamed 'a' -> 'd/a'
  $ cat a
  1

I remember some implementation where mv(1) really was just a rename(2),
which failed when crossing file systems.  Was it some HP-UX or Solaris mv(1)?
mv(1) has learned to copy+delete over time, which is what people would
expect from a "move".

My point is that "exchange" is a different functionality.
It's well somehow belonging and related to what renameat(2) is doing in the 
kernel,
and therefore it comes in handy that we can simply call it with an additional 
flag.
Yet it's IMO a different operation.  I bet there had been discussions whether
to create a new syscall, but apparently it was easier to put it with a flag
into an existing one.  Fine for the kernel.

On userland OTOH, we have broader choice.
Karel did his choice in util-linux for exch(1), and coreutils could expose
the same functionality.

For other feature requests, we were much more reluctant in coreutils ... for
good reasons: feature bloat, maintainability, etc.

So I'm asking myself what is different this time?
- The feature already exists -> util-linux.
- Okay, we're using the same syscall, renameat(2) -> it's tempting.
- How large is the useful overlap with the existing code of mv(1)?
  Not much: no traditional rename nor copy.
- How large is the useful overlap with the existing options/modes of mv(1)?
  - exchange contradicts --backup,
  - exchange is not useful together with options working with a regular
rename of copy, at least: --update, -Z, -n.
  - not sure if exchange works well together with -f.

I'm currently only 20:80 for adding it to mv(1).
The functionality is cool, but do we need to press it into mv(1) with so many
incompatibilities just because it's requiring renameat(2) we already use?
Maybe to consider: One tool for one thing ... means another tool for another 
thing.

Again, I have the gut feeling that we've missed some cases to think about.
And once the feature would be in ...

Furthermore, why does exchange not work to exchange a regular with a directory 
file?
We've all learned that everything's a file, so it cannot be explained to users 
that
exchanging a regular file with a directory doesn't work.

Finally, the test cases are very sparse: no cases with different owners, 
different
directory permissions, different file types (if we know already f<->d doesn't 
work),
triggering races, etc.

I don't really want to object to add it, but I find it quite odd as of today.

Have a nice day,
Berny

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

[Bernhard Voelker]

On 3/17/24 07:10, Paul Eggert wrote:

Although removing that "mv --swap" implementation was a win, I don't
think we can simply delegate this to util-linux's exch command.


I still have some headache adding this.

This stems from the fact that although mv(1) is a userland frontend
for renameat(2), the user interface is different:
while renameat(2) deals exactly with 2 operands, mv(1) has always
been able to work on more arguments.

Now, extending "exchange" to more arguments is confusing and the
use is not intuitive:
  mv -v --exchange  a b c d

An "exchange" can literally only be applied to 2 files,
and 'exch' is IMO fine.

I have the gut feeling that we didn't think through all cases,
and that some might be surprising, e.g.:

  $ mkdir d; echo 1 > a; echo 2 > d/a
  $ src/mv --exchange a a a a d/a

versus

  $ src/mv --exchange a a a a d/a

Have a nice day,
Berny

bug#68866: man page description of pwd command has error I guess

[Bernhard Voelker]

tag 68866 notabug
close 68866
stop

On 2/1/24 04:09, Seungchul Lee wrote:

man page description has following line,
"If no option is specified, -P is assumed."
But in my machine, its default behavior seems -L without any option for pwd.


'man pwd' and 'env pwd --help' also tells:

  NOTE: your shell may have its own version of pwd, which usually supersedes
  the version described here.  Please refer to your shell's documentation
  for details about the options it supports.

Are you sure that you are running pwd(1) from GNU coreutils, or that of the 
shell?

  $ pwd# pwd of the shell
  /home/berny/osc

  $ env pwd# pwd of GNU coreutils
  /media/osc

  $ /usr/bin/pwd   # pwd of GNU coreutils
  /media/osc

Have a nice day,
Berny

bug#62572: cp --no-clobber behavior has changed

[Bernhard Voelker]

On 12/15/23 21:13, Michael Stone wrote:

On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote:

Stlll, Pádraig gave a reasonable summary of why the change was made,
despite its incompatibility with previous behavior. (One thing I'd add
is that the FreeBSD behavior is inherently less race-prone.)


Whether the implementation is race-prone or not is an internal thing.
I think we're currently discussing more on a user-perspective level.

IIUC then the question is whether `cp -n` should continue to behave like
the (new) `cp --update=none` which returns EXIT_SUCCESS.

Regardless what other implementations do, when reading the -n description
from a user's point of view:

  -n, --no-clobber do not overwrite an existing file (overrides a
 -u or previous -i option). See also --update

then I'd expect the tool to just skip existing files like `rsync 
--ignore-existing`
does.  In that regard I would be surprised if skipping files would result in an 
error.
Well, I would understand if there'd be a '--no-clobber=fail' option.

As Kamil added the option in 2009, I'd assume that the same patch was already
active in RHEL versions for quite some longer time.
Now changing the exit code feels kind of rough.

Therefore, from a pure user's perspective and regarding many years of 
precedence,
I am 80:20 for reverting the exit code change.

Have a nice day,
Berny

bug#66176: 9.4 root test fails: tests/rm/ext3-perf tests/rm/ext3-perf.sh

[Bernhard Voelker]

On 9/23/23 18:35, Jeffrey Cliff wrote:

Test suite told me to send this report in so here we are.

environment : custom LFS (GNM)
coreutils: 9.4
gcc: (GCC) 13.2.0



> FAIL: tests/rm/ext3-perf
> 
> [...]
>
> ++ date +%s
> + start=1698065263
> + mkdir d
> + cd d
> + xargs touch
> + seq 40
> + test -f 1
> + test -f 40
> + cd ..
> + ok=1
> + test 1 = 1
> +++ date +%s
> ++ expr 1698065541 - 1698065263
> + setup_duration=278
> + echo creating a 40-entry directory took 278 seconds
> creating a 40-entry directory took 278 seconds
> + test 60 -lt 278
> + threshold_seconds=278
> ++ date +%s
> + start=1698065541
> + timeout 278s rm -rf d
> + err=124
> +++ date +%s
> ++ expr 1698065819 - 1698065541
> + duration=278
> + case $err in
> + fail=1
> + echo rm took longer than 278 seconds
> rm took longer than 278 seconds
> + echo removing a 40-entry directory took 278 seconds
> removing a 40-entry directory took 278 seconds
> + Exit 1

Hmm, that seems to be a rather slow system.
On my desktop system on ext4 here, it is:
  creating a 40-entry directory took 6 seconds
  removing a 40-entry directory took 4 seconds

The test measures the time for the creation, and uses it to verify
that the removal is faster.

Depending on other activities on the system during creation vs. that during
the deletion, the test might fail.

Is it always reproducible on that system, or was this just a one-off?

Have a nice day,
Berny

bug#64540: [PATCH] od: exit out on failure to write to stdout

[Bernhard Voelker]

On 7/15/23 23:08, Pádraig Brady wrote:

The attached patch-set addresses two classes of issue:
1. Doubled error messages upon write errors
2. Continued processing upon write errors  (the orig problem reported).


Nice work!

Patch 1:

> --- /dev/null
> +++ b/tests/misc/write-errors.sh
> @@ -0,0 +1,70 @@

> +if ! test -w /dev/full || ! test -c /dev/full; then
> +  skip_ 'Need /dev/full'

Other tests use a slightly different skip message:
  skip_ '/dev/full is required'

I'd favor the latter, so that we don't miss it once we'd like
to factor it out to a require_dev_full in init.cfg.

Re. patch 002:

> all: avoid repeated diagnostic upon write error
>
> * cfg.mk (sc_some_programs_must_avoid_exit_failure): Adjust to
> avoid false positive.
> (sc_prohibit_exit_write_error): A new syntax check to prohibit
> open coding error(..., "write error"); instead directiing to use...

s/ii/i/

> --- a/src/system.h
> +++ b/src/system.h
> @@ -762,6 +762,14 @@ The following directory is part of the cycle:\n  %s\n"), 
\
>  } \
>while (0)
>
> +static inline void
> +write_error (void)
> +{
> +  fflush (stdout);/* Ensure nothing buffered that might induce an error. 
*/
> +  clearerr (stdout);  /* To avoid extraneous diagnostic from close_stdout.  
*/
> +  error (EXIT_FAILURE, errno, _("write error"));
> +}

Hmm, fflush could theoretically change errno, couldn't it?
In that case, error() would give a wrong diagnostic.
FWIW: `man clearerr` states that this function doesn't touch errno.

Thanks & have a nice day,
Berny

bug#64326: Some more info about rm bug

[Bernhard Voelker]

tag 64326 notabug
close 64326
stop

On 6/28/23 19:33, Chris Elvidge wrote:
> On 28/06/2023 16:41, Arsen Arsenović via GNU coreutils Bug Reports wrote:
>> Hi,
>>
>> LitHack  writes:
>>
>>> Basically what it doing is that it doesn't recognise (-) this as a file
>>> name part even when using (\-). This bug will work on most of utilities
>>> like cat, cp etc
>>
>> This is simply how argument parsing and shell syntax work.  'rm \-abc'
>> is equivalent to just 'rm -abc', which is parsed as 'rm -a -b -c'.  To
>> delete a file with a dash at the start of its name, use 'rm ./-file' and
>> similar.
>>
>> Hope that helps, have a lovely day.

> Or rm -- -abc
>
> The "double-dash" signals "end of options"

And finally: FAQ #11 - #13:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#How-do-I-remove-files-that-start-with-a-dash_003f

I'm hereby closing this issue as not-a-bug.

Have a nice day,
Berny

bug#63732: Tailing Difficulities

[Bernhard Voelker]

tag 63732 notabug
close 63732
stop

On 5/26/23 02:26, Greg Carter via GNU coreutils Bug Reports wrote:

Got this when executing `tail -f install/MYSYBASE.log` for an SAP ASE
message log (a text file) with a Docker container:
```
tail: unrecognized file system type 0x794c7630 for 'install/MYSYBASE.log'.
please report this to bug-coreutils@gnu.org. reverting to polling
```

Thanks for the report.

That docker image seems to use a quite old coreutils version:
'overlayfs' - commonly used with Docker containers - has been added
in version 8.25 which was released in 2016.
Consider upgrading Coreutils if possible - we're at 9.3 currently.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

Have a nice day,
Berny

bug#61530: sha256sum check single file in a mutiple sha sum text file

[Bernhard Voelker]

tag 61530 notabug
close 61530
stop

On 2/15/23 14:28, Andreas Löw wrote:

Hello,

I want to check a single file for correct sha256. All the files of my
directory are included in a sha256 text file named allsha256.

The sha256sum always checks all files included in the allsha256 file,
even if I write:

sha256sum myfile -c allsha256

It reports a warning 'no correct formatted line was found for myfile'
and later it reports 'myfile OK'

Regards,
Andreas


The *sum utilities always check all files given in a checksum file(s).
That means once you've passed the -c option, the utility will treat all
further arguments as the name of files with checksums - no matter if the
file appears before or after the -c option:

  $ sha256sum README NEWS> checksum1
  $ sha256sum TODO configure > checksum2
  $ sha256sum checksum1 -c checksum2
  README: OK
  NEWS: OK
  TODO: OK
  configure: OK

To achieve what you want, you have to pass only the checksum line of the
file you want, e.g.:

  $ grep myfile allsha256s | sha256sum -c -
  myfile: OK

Therefore, I'm hereby marking this as not-a-bug in our bug tracker.

Have a nice day,
Berny

bug#61248: uniq --unique needs examples

[Bernhard Voelker]

On 2/3/23 08:12, Dan Jacobson wrote:

uniq INFO page says:
‘-u’
‘--unique’
  Discard the last line that would be output for a repeated input
  group.  When used by itself, this option causes ‘uniq’ to print
  unique lines, and nothing else.

This really needs some examples, to help people understand what it means.


While an example is always nice, isn't the last part of the above exactly
telling what it's doing?

  $ printf '%s\n' a a a b c c | uniq -u
  b

Admittedly, the --help output is both much shorter and clearer:

-u, --unique  only print unique lines

Have a nice day,
Berny

bug#60512: tail: unrecognized file system type 0x794c7630

[Bernhard Voelker]

tag 60512 notabug
close 60512
stop

On 1/3/23 10:27, 闵续 wrote:

tail: unrecognized file system type 0x794c7630 for ‘douyin.search.api.log’.
please report this to bug-coreutils@gnu.org. reverting to polling


Thanks for the report.

That docker image seems to use a quite old coreutils version:
'overlayfs' - commonly used with Docker containers - has been added
in version 8.25 which was released in 2016.
Consider upgrading Coreutils if possible - we're at 9.1 currently.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

Have a nice day,
Berny

bug#59461: please help me

[Bernhard Voelker]

tag 59461 notabug
close 59461
stop

On 11/21/22 10:21, 林兴隆 wrote:

OS:  Rocky Linux release 9.0 (Blue Onyx)
kenel:   5.14.0-70.22.1.el9_0.x86_64
Docker： 20.10.21, build baeda1f
Docker-Compose： v2.11.2

I use docker compose to run a container activemq，The contents are as 
follows，Error encountered，How can I solve it？please help me.

version: '3'
services:
   nacos:
 image: webcenter/activemq
 container_name: activemq
 hostname: activemq
 restart: always
 deploy:
   mode: replicated
   replicas: 1
   resources:
 limits:
   cpus: '2'
   memory: 2G
 reservations:
   memory: 200M
 env_file:
   - /data/activemq/env/activemq.env
 ports:
   - "8161:8161"
   - "61613:61613"
   - "61616:61616"
   - "1883:1883"
   - /data/activemq/data:/data/activemq
   - /data/activemq/logs:/var/log/activemq
①
②
③
④


Please avoid screenshots of textual terminal text: it's bloat, it's hard to
copy/paste to reproduce, and may therefore be ignored on this mailing list.

AFAICS, there's no error related to the GNU coreutils in the files you sent.
Instead, there are error messages of other software, e.g. search for "CRIT".
You may get better support for the actual error in forums or mailing lists
of the software which emits those errors.

Re. coreutils, there's only this warning which probably tempted you to send
this bug report:

> tail: unrecognized file system type 0x794c7630 for ‘dock2.log’. please
> report this to bug-coreutils@gnu.org. reverting to polling

That docker image obviously uses a quite old coreutils version:
overlayfs - commonly used with Docker containers - has been added
in version 8.25 which was released in 2016.
Consider upgrading Coreutils if possible - we're at 9.1 currently.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

As this is not a bug in our software, I'm hereby closing this issue in our bug 
tracker.

Have a nice day,
Berny

bug#59304: tail: unrecognized file system type 0x794c7630

[Bernhard Voelker]

tag 59304 notabug
close 59304
stop

On 11/16/22 05:44, Stuart Rothrock wrote:

tail -f /var/log/melog | while read a; do echo $(date) $(echo $a | sed -e
's/[{}",]//g' -e 's/[a-z]\+://g'); done 2>&1 | tee -a dock2.log

tail -f power-dock2.log
tail: unrecognized file system type 0x794c7630 for ‘dock2.log’. please
report this to bug-coreutils@gnu.org. reverting to polling

Thanks guys!!


Thanks for the report.

That docker image seems to use a quite old coreutils version:
overlayfs - commonly used with Docker containers - has been added
in version 8.25 which was released in 2016.
Consider upgrading Coreutils if possible - we're at 9.1 currently.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

Have a nice day,
Berny

bug#56631: flock does not unlock instantly

[Bernhard Voelker]

tag 56631 notabug
close 56631
stop

On 7/18/22 12:50, Alexey Kuznetsov wrote:
> Simple bash script:
> 
> #!/bin/bashset -eexec 7<"$0"flock -n 7sleep 60
> 
> Will prevent a second instance from being executed (exits instantly). But
> if the first instance got killed by 'killall test.sh', the second instance
> of the script can be executed only after 60 seconds. First instance of the
> script does report being killed instantly, but still does not let me run
> the second instance of the script. That makes me think, sleep command not
> being killed / handled correctly. Here is a work around example, using the
> following script makes it work correctly:
> 
> #!/bin/bashset -etrap "kill 0" SIGINT SIGTERMexec 7<"$0"flock -n 7sleep 60
> 
> 
> Flock waits until sleep finishes, even when the script holding lock is
> killed. Is it a bug or feature?

First of all, only sleep(1) is relevant here for the coreutils mailing list;
flock(1) is part of util-linux, and theoretically also the shell could play
into the game.

As I see it, flock(1) calls flock(2) - as can be seen by 'strace -vf ./script':

  [pid 13705] flock(7, LOCK_EX|LOCK_NB)   = 0

Looking at `man 2 flock`:

   Locks created by flock() are preserved across an execve(2).

So it's no surprise that sleep(1) inherits and therefore continues
to hold the lock until its own termination.

As such, I'm closing this bug in the coreutils bug tracker, because sleep(1)
does not do anything different from what any other program would do.
Of course, the discussion can continue.

Have a nice day,
Berny

bug#55837: Options `-p` and `--tmpdir` behave differently

[Bernhard Voelker]

tag 55837 notabug
close 55837
stop

On 6/8/22 02:28, Klaatu wrote:

According to the man page, `--tmpfile` is the long option for `-p`
However, I get different results when using one or the other.
The `-p` option results in success:


$ mktemp -p ~/Demo
/home/klaatu/Demo/tmp.6TWPxScyKK
$ mktemp -p ~/Demo XXX
/home/klaatu/Demo/KdC


However, `--tempdir` results in failure:


$ mktemp --tmpdir ~/Demo
mktemp: too few X's in template ‘/home/klaatu/Demo’
$ mktemp --tmpdir ~/Demo XXX
mktemp: too many templates
Try 'mktemp --help' for more information.


The option --tmpdir is indeed the long option for -p, but it has to be used with
it's argument following immediately and beginning after the '=' character:

  $ mktemp --help | grep -- '-p.*tmpdir'
-p DIR, --tmpdir[=DIR]  interpret TEMPLATE relative to DIR; if DIR is not

As the documentation states, the argument is optional, and therefore `mktemp`
took ~/Demo as pattern instead of argument to --tmpdir.

Use `mktemp --tmpdir=/some/dir` instead.


$ mktemp --tmpdir='~/Demo' XXX
mktemp: failed to create file via template ‘~/Demo/XXX’: No such file or
directory



In this last code example, `mktemp` will receive the '~/Demo' literally because
the calling shell doesn't replace it with the real path (like 
/home/someuser/Demo)
as it usually would do without the quoting; therefore `mktemp` fails to create
a file there.

The program works as specified, and therefore I'm marking this as not a bug.

Have a nice day,
Berny

bug#53674: Docker error code: 0x794c7630

[Bernhard Voelker]

tag 53674 notabug
close 53674
stop

On 2/1/22 03:38, Alexandre Louisdhon wrote:
> Error-  tail: unrecognized file system type 0x794c7630 for
> ‘/var/log/syslog’.

Thanks for the report.

That docker image seems to use a quite old coreutils version:
overlayfs - commonly used with Docker containers - has been added
in version 8.25 which was released in 2016.
Consider upgrading Coreutils if possible - we're at 9.0 currently.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

Have a nice day,
Berny

bug#53212: feature request: mount option to specify the device number

[Bernhard Voelker]

tag 53212 notabug
close 53212
stop

On 1/12/22 17:59, Joachim Wagner wrote:
> Not sure whether this is coreutils or kernel. Maybe both.
> 
> A filesystem's device number such as reported by `stat` can be derived from 
> major and minor of the underlying block device, e.g. xfs, or be allocated at 
> mount time, e.g. btrfs. Even in the former case, the device number can change 
> between restarts, e.g. when multiple dm-crypt devices are created in 
> different 
> order. Changing device numbers cause trouble for applications that use the 
> device number to identify a filesystem across restarts, e.g. KDE's baloo file 
> indexer.
> 
> A mount option to specify the device number would fix this trouble without 
> requiring applications to move to alternative ways of identifying 
> filesystems, 
> e.g. based on UUIDs. This option could be general, i.e. the device number can 
> be set for any filesystem, including those that normally derive it from major 
> and minor of their block device(s).
> 
> The implementation would probably be simplified if the specified device 
> numbers must come from a reserved pool. Otherwise, care must be taken that 
> the 
> numbers do not collide with automatically assigned device numbers, including 
> those allocated later.
> 
> Replaces bug #53209
> 
> References:
> https://bugs.kde.org/show_bug.cgi?id=402154
> https://bugs.kde.org/show_bug.cgi?id=404057
> https://bugs.kde.org/show_bug.cgi?id=413694
> https://unix.stackexchange.com/questions/345220/btrfs-how-to-get-real-device-id
> https://stackoverflow.com/questions/4309882/device-number-in-stat-command-output/4309947

mount is a command from the util-linux package, hence you'd be better off asking
on their mailing list .

FWIW: mount already knows quite a list of alternatives how to specify the source
device:

  mount --help | sed -n '/^Source:/,/^$/p'
  Source:
   -L, --label  synonym for LABEL=
   -U, --uuidsynonym for UUID=
   LABEL=   specifies device by filesystem label
   UUID= specifies device by filesystem UUID
   PARTLABEL=   specifies device by partition label
   PARTUUID= specifies device by partition UUID
   ID= specifies device by udev hardware ID
   specifies device by path
mountpoint for bind mounts (see --bind/rbind)
 regular file for loopdev setup

As this is not related to coreutils, I'm hereby closing this issue in our
bug tracker.

Have a nice day,
Berny

bug#53209: stat shows wrong, non-existing device number

[Bernhard Voelker]

On 1/12/22 16:35, Joachim Wagner wrote:
> I cloned git://git.sv.gnu.org/coreutils to add a sentence on this to stat's 
> man page but coreutils/man/stat.x is only a template, missing what I see in 
> `man stat` on my system. Trying to find out how to contribute to 
> documentation, I encountered the following cycle with no answer:
> 
> https://www.gnu.org/help/
> https://www.gnu.org/philosophy/free-doc.html
> https://www.gnu.org/doc/doc.html
> https://www.gnu.org/help/help.html#helpgnu

Typically, the first thing to look at are the README* files, especially
'README-hacking'.

Re. man pages of the coreutils:

a) they are generated during the build from the output of "$UTIL --help"
plus the information in "man/$UTIL.x".

b) The information in the man pages should be kept as terse as possible,
and more detailed information should go into the Texinfo manual (which also
gets uploaded to https://www.gnu.org/software/coreutils/manual/ in HTML,
PDF and other formats after each release).

Have a nice day,
Berny

bug#53145: 回覆: bug#53145: Acknowledgement ("cut" can't segment Chinese characters correctly?)

[Bernhard Voelker]

On 1/12/22 12:19, zendas via GNU coreutils Bug Reports wrote:
> I have considered dealing with this problem directly with three bytes 
> instead, but I have two doubts, I can correctly use wc -m to recognize the 
> bytes in the same environment (but cut can't?), and my script goal is to 
> recognize Chinese, will The probability of execution is higher on platforms 
> that support Chinese environment. In addition, the fixed three-byte approach 
> cannot handle the mixed content of full shape and half shape. I need a lot of 
> judgment and conversion, which will greatly increase the possibility of 
> errors.

As Bob wrote, some downstream distributions have multi-byte support in cut(1) 
for many years,
e.g. RHEL/Fedora and SUSE/openSUSE.

E.g. here on my openSUSE system:

  $ echo "你好啊" | LC_ALL=zh_CN.UTF-8 cut -c 1
  你

Have a nice day,
Berny

bug#52122: mv: deletes src file on error

[Bernhard Voelker]

On 11/26/21 13:23, Frank Busse wrote:
> I tried it several times with checking the timestamps/md5sums of the
> files but after remounting the stick it doesn't happen anymore?! I
> guess it was a hiccup somewhere else in the system, sorry.

Perhaps the USB stick was removed from the system before the kernel
could flush the data?

Have a nice day,
Berny

bug#52115: Suggestion: LN command should swap TARGET and LINK_NAME if LINK_NAME already exists

[Bernhard Voelker]

On 11/26/21 00:10, Warren Parad wrote:
> On Fri, Nov 26, 2021 at 12:02 AM Bernhard Voelker  <mailto:m...@bernhard-voelker.de>> wrote:
>> The synopsis is already complex and confusing enough:
>
> Opinion, it is as complex as it allows, sounds like you are saying "LN Sucks, 
> we really need 4 commands
> which are all simpler", sure okay we can have another command, but doing the 
> right thing ALWAYS takes
> precedence over "I have an opinion".

That is my opinion, correct.
Yet there's also standardization (POSIX) and 40+ years of known behavior.  
Adding functionality has to be
well-thought and must not contradict any existing usage, nor open doors for 
more surprises to users.
Finally, there's compatibility to other implementations to consider.

>> what happens if another (malicious?) user B creates LINK_TARGET while user A 
>> is typing the command?
>
> While typing before entering? Then it doesn't matter if they are reversed 
> since the command would still fail because
> both exist, that should result in the only real failure. I'm not suggesting 
> removing the error in all cases.

That's the point: the outcome would greatly depend on whether LINK_TARGET is 
created as regular file
or as a directory.  And no, one cannot predict when another process is 
modifying the file system.
IMO this is more surprising and therefore inconvenient than to get an error 
message if the
user missed to put TARGET and LINK_NAME in the correct order.

Have a nice day,
Berny

bug#52115: Suggestion: LN command should swap TARGET and LINK_NAME if LINK_NAME already exists

[Bernhard Voelker]

On 11/25/21 18:53, Warren Parad wrote:
> It is too frequent a problem to know which is the correct order of TARGET
> and LINK_NAME.

I disagree: it is a one-time effort to learn the order ... similar as
for mv(1) and cp(1).

> Since the command already believes that it can't create a link to a file
> which already exists (and for hard links that the TARGET must also exist),
> instead of complaining, the command should just switch the order of the
> parameters.

The synopsis is already complex and confusing enough:

  Usage: ln [OPTION]... [-T] TARGET LINK_NAME
or:  ln [OPTION]... TARGET
or:  ln [OPTION]... TARGET... DIRECTORY
or:  ln [OPTION]... -t DIRECTORY TARGET...

and especially surprising if LINK_NAME is a directory name which the caller
wasn't aware of.  Letting ln(1) automagically swap the parameters if LINK_NAME
exists simply adds more confusion and opens maybe a big race window:
what happens if another (malicious?) user B creates LINK_TARGET while user A
is typing the command?

Personally, I recommend the following option combination which results in
less surprises (see other cases below):

  $ ln -nsvf somename othername

Especially when creating symlinks, I prefer to get an error early rather than
ending up with a symlink with a name or location I never would have expected.

Have a nice day,
Berny

bug#52033: a bug in paste command

[Bernhard Voelker]

tag 52033 notabug
close 52033
stop

On 11/22/21 14:39, Visser, Gerard wrote:
> Please close the case.

Hereby done.

bug#51311: [PATCH] echo: update --help to document edge cases

[Bernhard Voelker]

On 10/22/21 16:21, Pádraig Brady wrote:
> Thanks for all the input.
> I've now pushed the following to address this:
> 
> https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=f60a3981c
> 
> Notes:
>   - Brevity in --help and man pages is a feature
>   - I kept the existing NOTE: style in --help to avoid a separate [NOTES] in 
> man
>   - I only detailed the edge cases in the info manual,
>   as directing users to printf(1) is the better most general option
>   - It's easy to get to online info pages now by following the link
>   at the bottom of all man pages

Thanks, I like it.

FWIW the biggest trap for users is still that in ~95% of the cases it is the
shell's builtin which gets called instead of that of the coreutils.
Hence, we've been improving the documentation for the users which
unsuspectingly read coreutils 'man echo' instead of that of the shell.

Have a nice day,
Berny

bug#51311: [PATCH] echo: update --help to document edge cases

[Bernhard Voelker]

On 10/21/21 15:14, Florent Flament wrote:
> Pádraig Brady  writes:
>> +NOTE: printf(1) is a preferred alternative, with more standard option 
>> handling.\

> I believe that it misses the point. It is still not clear that the echo
> command doesn't behave as one would expect for a few edge cases.
> 
> Maybe something like this would be closer to what I'm trying to express:
> 
> NOTE: printf(1) is a preferred alternative, which doesn't share echo's
> inability to handle edge cases.

I'm not sure that just mentioning "edge cases" will remind people either
that they are falling into such particular edge case.

Therefore, I'd prefer Padraig's shorter sentence: it expresses the matter
positively while the latter proposal tries to explain via negative wording.

If we want to be more explicit, then we'd have to name examples where
printf(1) is superior to echo(1) - or the shell's echo builtin.
But IMO the whole point is two-fold: if someone doesn't have enough experience
to understand the edge cases, then eventually the usage of printf with the
often complex format specifiers is also too much.
Finally, I think Padraig's suggestion had the best tradeoff between pointing
out the matter and getting too much into details.

Have a nice day,
Berny

bug#51011: [PATCH] sort: --debug: add warnings about radix and grouping chars

[Bernhard Voelker]

On 10/10/21 19:57, Pádraig Brady wrote:
>sort: numbers use ‘.’ as a decimal point in this locale

What about adding the hint to that message that this an "ambiguity warning"?

sort: ambiguity warning: numbers use ‘.’ as a decimal point in this locale

(Likewise for the other cases, of course.)

Most other --debug messages usually state how sort processes the options / the
input, while this one tells why the processing potentially does not work as the
user expected.

+1 otherwise.

Have a nice day,
Berny

bug#50784: coreutils 9.0 sometimes gets spurious failures in chmod -R

[Bernhard Voelker]

On 9/24/21 22:02, Pádraig Brady wrote:

Tested equivalent patch is attached.


Nice small patch.
Maybe it's worth documenting in the enum where the "bad range" starts against 
which the
code later tests?
Furthermore, I think it's worth adding a NEWS entry and mentioning that this 
bug has been
introduced in v9.0, namely in v8.32-193-gbbb19b186.

Thanks & have a nice day,
Berny

bug#50167: fixes for "fmt - -" etc.

[Bernhard Voelker]

On 8/25/21 10:38 AM, Jim Meyering wrote:
> * cfg.mk (exclude_file_name_regexp--sc_system_h_headers):
> Add find-mount-point.h to the regexp.

+1
even better, thanks.

Have a nice day,
Berny

bug#50167: fixes for "fmt - -" etc.

[Bernhard Voelker]

Hi Paul,

On 8/22/21 10:12 PM, Paul Eggert wrote:
> Subject: [PATCH 4/4] df: pacify -Wsuggest-attribute=malloc
>
> Problem found with latest Gnulib and GCC 11.2.1.
> * src/find-mount-point.h (find_mount_point):
> Add _GL_ATTRIBUTE_MALLOC and _GL_ATTRIBUTE_DEALLOC_FREE.
> ---
>  src/find-mount-point.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/find-mount-point.h b/src/find-mount-point.h
> index 028b2500c..a1bbcdc92 100644
> --- a/src/find-mount-point.h
> +++ b/src/find-mount-point.h
> @@ -14,4 +14,7 @@
> You should have received a copy of the GNU General Public License
> along with this program.  If not, see <https://www.gnu.org/licenses/>.  */
>
> -extern char *find_mount_point (char const *, struct stat const *);
> +#include 
> +
> +extern char *find_mount_point (char const *, struct stat const *)
> +  _GL_ATTRIBUTE_MALLOC _GL_ATTRIBUTE_DEALLOC_FREE;

`make syntax-check` complains:
  src/find-mount-point.h:17:#include 
  maint.mk: the above are already included via system.h
  make: *** [cfg.mk:174: sc_system_h_headers] Error 1

The attached fixes it.
Was there a particular reason to include stdlib.h?

Have a nice day,
Berny
>From fd277435c8cc4b758c101b9466fd8e86f4f37807 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Tue, 24 Aug 2021 21:32:26 +0200
Subject: [PATCH] maint: avoid sc_system_h_headers error

`make syntax-check` complains:
  src/find-mount-point.h:17:#include 
  maint.mk: the above are already included via system.h
  make: *** [cfg.mk:174: sc_system_h_headers] Error 1

* src/find-mount-point.h (#include ): Remove again.
---
 src/find-mount-point.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/find-mount-point.h b/src/find-mount-point.h
index a1bbcdc92..be0d367be 100644
--- a/src/find-mount-point.h
+++ b/src/find-mount-point.h
@@ -14,7 +14,5 @@
You should have received a copy of the GNU General Public License
along with this program.  If not, see <https://www.gnu.org/licenses/>.  */
 
-#include 
-
 extern char *find_mount_point (char const *, struct stat const *)
   _GL_ATTRIBUTE_MALLOC _GL_ATTRIBUTE_DEALLOC_FREE;
-- 
2.32.0

bug#50169: Linux cp missing destination file

[Bernhard Voelker]

On 8/22/21 8:26 PM, Diana ladydi_r wrote:
> Linux cp bug is happening when I am in wadam@localhost ~]$

That just shows a command prompt, and nothing related to cp(1) or coreutils at 
all.

> What can I do?

You failed to provide the information for any of the typical questions like:

- what do you want to achieve? -> verbose description
- how did you try to do it? -> command which was run
- what was the input for the operation? -> coreutils version, operating system,
  input files, environment variables, other prerequisites, ...
- what is the expected outcome?
- what was the actual outcome?
- what exact error messages do you see?

in short: a reproducer.

Have a nice day,
Berny

bug#49716: no -print0 for ls?

[Bernhard Voelker]

On 7/26/21 5:00 PM, Pádraig Brady wrote:
> The patch set looks good thanks.

Wait - I see another reason why we didn't add it earlier:

The --null option is not compatible with about half of the other options of 
ls(1);
at least the actual output is more than questionable, and not usable in 
programmatic
context.  The -R option is the first one which obviously can't work as such.

The following options don't work well with --null, because they output other,
additional information or transform/escape the file names:

  -b, --escape   print C-style escapes for nongraphic characters
  -C list entries by columns
  --color[=WHEN] colorize the output; WHEN can be 'always' (default
   if omitted), 'auto', or 'never'; more info below
  -F, --classify append indicator (one of */=>@|) to entries
  --file-typelikewise, except do not append '*'
  --full-timelike -l --time-style=full-iso
  -g like -l, but do not list owner
  --indicator-style=WORD  append indicator with style WORD to entry names:
   none (default), slash (-p),
   file-type (--file-type), classify (-F)
  -i, --inodeprint the index number of each file
  -l use a long listing format
  -m fill width with a comma separated list of entries
  -n, --numeric-uid-gid  like -l, but list numeric user and group IDs
  -o like -l, but do not list group information
  -p, --indicator-style=slash
 append / indicator to directories
  -q, --hide-control-chars   print ? instead of nongraphic characters
  -Q, --quote-name   enclose entry names in double quotes
  --quoting-style=WORD   use quoting style WORD for entry names:
   literal, locale, shell, shell-always,
   shell-escape, shell-escape-always, c, escape
   (overrides QUOTING_STYLE environment variable)
  -R, --recursivelist subdirectories recursively
  -s, --size print the allocated size of each file, in blocks
  -x list entries by lines instead of by columns
  -Z, --context  print any security context of each file

While the actual change is small - i.e., change the newline to a '\0' for the 
eolchar,
I'm afraid that it will become quite hairy to discuss the actual problems of 
future users
of that option when combining it with one of the above options.

I really have some qualms with adding --null to ls(1).  If this is about 
listing files
in the current directory in a certain sort order for a processing purpose, then 
this
would IMO warrant a new utility rather than blowing ls(1).

Have a nice day,
Berny

bug#48330: The xargs -r, --no-run-if-empty Option Is Ignored When a Delimiter Is Passed

[Bernhard Voelker]

tag 48330 notabug
close 48330
stop

On 5/10/21 8:07 AM, Kurt von Laven wrote:
> [[ $input = *[![:space:]]* ]] && xargs --null -I str echo str <<< "$input"

You have reached the GNU coreutils mailing list, and 'xargs' is not part
of the coreutils [1].

[1] https://www.gnu.org/software/coreutils/

Instead, 'xargs' is part of the 'findutils' package, so you're better off asking
on their mailing list or bug tracker.

  $ xargs --help | tail -n4
  You can report (and track progress on fixing) bugs in the "xargs"
  program via the GNU findutils bug-reporting page at
  https://savannah.gnu.org/bugs/?group=findutils or, if
  you have no web access, by sending email to .

I'm therefore marking this as "not a bug" + "closed" in the coreutils bug 
tracker.

Have a nice day,
Berny

bug#48070: sort.exe cannot do ascii ordering but help says it can.

[Bernhard Voelker]

On 4/27/21 7:39 PM, Peter SMITH1 (contractor) via GNU coreutils Bug Reports 
wrote:
> CONFIDENTIAL & RESTRICTED

This cannot be enforced on a public mailing list, for obvious reasons.

> Hello,
> 
> C:\gener\gnuutils>\bin\sort --version
> sort (GNU coreutils) 5.3.0
> Written by Mike Haertel and Paul Eggert.
> 
> Copyright (C) 2005 Free Software Foundation, Inc.

This is a report with a 16-year-old version of the tool.
Not sure if the issue - if any - still exists in the current version (8.32)

Furthermore, you are using a Windows binary - usually one would try to
seek help at the creator of that, i.e., the distributor, first.

> C:\gener\gnuutils>type test.dat
> 
> 
> 
> 
> 
> C:\gener\gnuutils>set LC_ALL=C
> 
> C:\gener\gnuutils>\bin\sort test.dat
> 
> 
> 
> 
> 
> C:\gener\gnuutils>

It seems that the locale information available to sort differs from that
of a current system:

  $ env LC_ALL=C sort test.dat
  
  
  
  

or that your version of sort enables case-folding (-f):

  $ LC_ALL=C sort -f test.dat
  
  
  
  

As the version you are using is that old, and the environment is quite 
different,
I'm afraid we cannot help much here.  First, I'd try to get a newer build and
see if the problem still exists.

Have a nice day,
Berny

bug#47859: Additional seq outlandish example: seq 0 dangers

[Bernhard Voelker]

On 4/18/21 3:26 AM, 積丹尼 Dan Jacobson wrote:
> Here's another 'fun/sad/DDOS yourself' example you might add:
> 
> One day I wrote a Makefile,
> m:
>   seq 0 9|sed s/$$/號.html/|xargs make
> but before using it, I though I'll just test with one item,
> m:
>   seq 0  |sed s/$$/號.html/|xargs make
> well of course... as seq prints nothing here,
> this triggered a massive ever growing recursive loop...
> 
> Yes, all my fault for picking 0. I'll pick 1 next time.

Besides the main discussion about seq(1), I want to add that xargs(1) [0]
is often run most usefully with:

  -r, --no-run-if-emptyif there are no arguments, then do not run 
COMMAND;
 if this option is not given, COMMAND will be
 run at least once

Portability hint:
Unfortunately, the -r option is not required by POSIX.  At least, the BSD family
(FreeBSD [1], NetBSD [2], OpenBSD [3]) has it; on Solaris [4], only the '1g'
variant [5] has it.  Not sure about other implementations.

[0] 
https://www.gnu.org/software/findutils/manual/html_node/find_html/xargs-options.html
[1] https://www.freebsd.org/cgi/man.cgi?xargs
[2] https://man.netbsd.org/xargs.1
[3] https://man.openbsd.org/xargs.1
[4] https://docs.oracle.com/cd/E88353_01/html/E37839/xargs-1.html
[5] https://docs.oracle.com/cd/E88353_01/html/E37839/xargs-1g.html

Have a nice day,
Berny

bug#47777: Feature request

[Bernhard Voelker]

On 4/14/21 9:43 PM, Stuart Blake Tener wrote:
>   Pádraig,
> 
> [...] your response [...] was a bit offensive.

I don't feel Padraig's reply was offensive at all.  Instead, he just
asked for further clarification about the requested feature.
Adding a clear example maybe would have helped.

> --include-type=parm1[,parm2,parm3...]
> A parameter representing a filesystem type to be additive to the  
> currently supported default list of filesystems.

The default list of file systems includes all but dummy filesystems which
do not occupy a backing store like e.g. the /proc or the /sys filesystems.

Therefore, if someone would like to have a certain type additionally
to that default list - which would obviously be such a dummy filesystem,
then this would be quite a strange corner case IMO.

As you mentioned ZFS in your original email, doesn't GNU df show that
per default?  That would be a bug.

> --include-replace
> this parameter overrides the default functionality of the  
> "--include-type" being additive to the currently supported list of  
> default filesystems and replaces that list with the filesystem or  
> filesystems so specified in the "--include-type" parameter.

Sound like -type.

Have a nice day,
Berny

bug#47324: AW: bug#47324: Missing information in documentation

[Bernhard Voelker]

On 3/23/21 11:18 AM, Walter Harms via GNU coreutils Bug Reports wrote:
> In my case there was no security context involved.
> It was a loop device mounted (that i was not aware of,
> the image was already gone).
> and rm -r stoped here because of "in use".
> 
> I expected some mentioning of mount somewhere.

According to the source code [1], the directory must have had a security
context set.

[1] https://git.sv.gnu.org/cgit/coreutils.git/tree/src/ls.c?id=4698e284f#n4243

So if it was a mount point, then the only logical conclusion is that the 
top-most
directory of the mounted filesystem had this security context set.
Reproducer:

  # Create an EXT4 file system and loop-mount it.
  $ dd if=/dev/zero of=x.img bs=1M count=128 status=none
  $ mkfs.ext4 -q x.img
  $ mount -o loop x.img /mnt

  # Initially, there's no security context, hence no '.' after the permission 
string.
  $ ls -ld /mnt
  drwxr-xr-x 3 root root 1024 Mar 25 23:54 /mnt

  # Apply a security context.
  $ setfattr -n security.selinux -v somevalue /mnt

  # Now, ls(1) prints the '.' after the permission string as a hint to the 
security context.
  $ ls -ld /mnt
  drwxr-xr-x. 3 root root 1024 Mar 25 23:54 /mnt

Have a nice day,
Berny

bug#47348: Possible bug coreutils : no cat command

[Bernhard Voelker]

On 3/23/21 12:22 PM, Luís via GNU coreutils Bug Reports wrote:
> I found that the cat command, supported by the Coreutils package 
> (8.30-ubuntu2) is no longer working.

That's quite a vague description, so no one will probably be able to help you 
based on that.

What exactly happens when you run e.g. `cat /etc/hosts`?

Have a nice day,
Berny

bug#47324: Missing information in documentation

[Bernhard Voelker]

On 3/22/21 5:37 PM, Walter Harms via GNU coreutils Bug Reports wrote:
> hi list,
> in the documentation (man page) [...]

According to the GNU guidelines and to avoid double work, the man page of
the coreutils is essentially not much more than the output of --help
(and actually gets generated via that).
Instead, the real documentation is available via the Texinfo manual,
which is available in diverse formats.  In a usual installation, it
is reachable via:
  $ info '(coreutils) ls invocation'
Alternative formats include HTML, PDF etc., see:
  https://www.gnu.org/software/coreutils/manual/

> [...] nice feature is mssing
> when a fs is mounted on a directory ls marks that with a dot
> behing the permission mask (see example)
> 
> drwxr-xr-x. 2 1003 users 4096 Mar 22 17:53 vendor
>  ^^
>  notice the dot here
> 
> I found nothing mentioned in the documentation.

It is documented in the section about the '-l' option:

  
https://www.gnu.org/software/coreutils/manual/html_node/What-information-is-listed.html

  [...]
  Following the file mode bits is a single character that specifies whether an
  alternate access method such as an access control list applies to the file.
  When the character following the file mode bits is a space, there is no 
alternate
  access method. When it is a printing character, then there is such a method.

  GNU ls uses a ‘.’ character to indicate a file with a security context, but no
  other alternate access method.

  A file with any other combination of alternate access methods is marked with 
a ‘+’ character.

Assuming that this section is clear enough, I'm hereby marking this as done
in our bug tracker. Of course, the discussion can continue, and we could even
reopen the issue if needed.

Have a nice day,
Berny

bug#47322: unrecognized file system type 0x794c7630

[Bernhard Voelker]

tag 47322 notabug
close 47322
stop

On 3/22/21 5:16 PM, Felipe Lima wrote:
> I was trying do tail a file in a docker container when I received that
> message:
> 
> ```
> tail: unrecognized file system type 0x794c7630 for
> ‘zookeeper-gc.log.0.current’. please report this to bug-coreutils@gnu.org.
> reverting to polling
> ```
> 
> The docker image name is:
> sentry_onpremise_zookeeper_1
> 
> And the zookeeper image is:
> image: 'confluentinc/cp-zookeeper:5.5.0'

Thanks for the report.

That docker image seems to use a quite old coreutils version:
overlayfs - commonly used with Docker containers - has been added
in version 8.25 which was released in 2016.
Consider upgrading Coreutils if possible - we're at 8.32 currently.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

Have a nice day,
Berny

bug#45832: CYBER HACK URGENT BUG REPORT

[Bernhard Voelker]

tag 45832 notabug
close 45832
stop

On 1/12/21 10:33 PM, hayley novelli wrote:
> https://www.gnu.org/software/coreutils/coreutils
> 
> 
> 
> https://dl.bintray.com/grimler/science-packages-24 science/stable aarch64 
> Packages [8936
> 
> 
> bintray located in s20 5g
> remote access
> 
> aarch64
> heimdallddata files
> daemons located
> sandbox
> z-ram
> USB update
> 
> your companion
> 
> activities in Google download
> screen share Microsoft
> free text & call apps
> 
> etc...
> 
> much more attachments to be forwarded now transferred to s9
> 
> after factory reset restore
> 
> 0433942419
> Hayley Michele
> 30 Louise avenue baulkham hills
> 2153

Sorry - is that a bug report?

You reached the GNU coreutils mailing list, but neither in the text provided
above nor in the (bloaty 3M!) screenshots I can see anything like a bug
description or a reproducer.

The only thing which is somehow clear is that you did something with
a (Samsung?) mobile phone, and that you live in Australia.
But I don't see the slightest relation to the coreutils, sorry.
Well, only the URL to the gnu.org page at the top.

Thus, I'm closing this as as not-a-bug in our bug tracker.

Have a nice day,
Berny

bug#45726: backup-to-s3 bug

[Bernhard Voelker]

tag 45726 notabug
close 45726
stop


On 1/8/21 5:41 AM, Admin Golky via GNU coreutils Bug Reports wrote:
> unrecognized file system type 0x794c7630 for '/var/log/cron.fifo'. please 
> report this to bug-coreutils@gnu.org. reverting to polling

overlayfs - commonly used with Docker containers - has been added
in version 8.25. We're currently at 8.32.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

I'm hereby closing this as not a bug in our bug tracker.

Have a nice day,
Berny

bug#45648: `dd` seek/skip which way is up?

[Bernhard Voelker]

On 1/5/21 3:06 AM, Paul Eggert wrote:
> On 1/4/21 3:07 PM, Bernhard Voelker wrote:
>> What 'dd' implementation was this specifically?
> 
> Solaris dd has iseek and oseek. However, they are not aliases for skip 
> and seek. If coreutils dd were to add these features I expect we should 
> do them the Solaris way, instead of making them aliases for skip and 
> seek. This would take more work than the proposed patches.
> 
> https://docs.oracle.com/cd/E36784_01/html/E36871/dd-1m.html

That would make the situation even more confusing for the user
... and more complex because such implementation would interfere
with GNU dd's seek/skip and iflag=skip_bytes and oflag=skip_bytes
functionality.  Doesn't sound like a good idea.

Have a nice day,
Berny

bug#45648: `dd` seek/skip which way is up?

[Bernhard Voelker]

On 1/4/21 4:03 AM, Bela Lubkin wrote:
> I constantly confuse 'seek=N' and 'skip=N'.  The two words have no natural
> affinity to one I/O direction or the other.

While the words 'seek' and 'skip' may not be strong enough for everyone
to be clear about whether they apply on input or output - e.g. for non-native
English speaker like myself - they are well documented in usage() and more 
places:

  $ dd --help | grep -E ' (skip|seek)=N '
seek=N  skip N obs-sized blocks at start of output
skip=N  skip N ibs-sized blocks at start of input

FWIW these terms are required by POSIX:

  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html

> I previously encountered a `dd` implementation which also accepted
> 'oseek=N' and 'iseek=N', which I found far more natural and easy to
> remember.

What 'dd' implementation was this specifically?

> Here is a small patch implementing the same for coreutils `dd`.

In my opinion: if the word chosen for an option is not clear enough
to distinguish from another one, then adding yet another alias would
just increase confusion.

Adding options to coreutils programs has to be carefully chosen.
The only reason I'd see to add such an alias would be existing
behavior in one of the other major implementations.

Have a nice day,
Berny

bug#45258: mkdir man page unclear in describing -m flag

[Bernhard Voelker]

On 12/16/20 2:34 PM, Pádraig Brady wrote:
> Insightful comments. I've updated the gotchas note with them:
> https://www.pixelbeat.org/docs/coreutils-gotchas.html#mkdir

Nice, and also better wording than mine, thanks!

Have a nice day,
Berny

bug#45258: mkdir man page unclear in describing -m flag

[Bernhard Voelker]

On 12/15/20 9:00 PM, Paul Eggert wrote:
> Thanks for your bug report. I installed the attached patch; although it
> doesn't use the exact wording you proposed, I hope it works well enough.

Thanks for clarifying.

> +If the @option{-m} option is also given, it does not affect
> +file permission bits of any newly-created parent directories.
> +To control these bits, set the
>  umask before invoking @command{mkdir}. [...]

Some further thoughts on this - maybe just for my reference:

One aspect of using -p is that the user doesn't want to get an error if
the target or any of its parent directories already exists.

If changing the umask before invoking mkdir is not that easy - maybe
because not called via a shell -, then an alternative to the above
umask method is to reference each of the target directories separately,
e.g.:
  $ mkdir -pm 0700  dir1  dir1/dir2  dir1/dir2/dir3

But it is important to know that 'mkdir' does not adjust the permission
bits of any of those already existing directories.

Therefore, if one does not want to get a failure for already existing
intermediate directories, and still wants their permission bits to get
adjusted, then one can use 'install' instead of 'mkdir' (still passing
each directory level as separate argument!):

  $ install -dm 0700  dir1  dir1/dir2  dir1/dir2/dir3

Have a nice day,
Berny

bug#45001: Ls bug

[Bernhard Voelker]

tag 45001 notabug
close 45001
stop

On 12/2/20 5:37 AM, Paul Morton wrote:
> Hello, I am using the command prompt linux to -1 a Ls
> 
> What can I do to acquire help from you.

A good bug report answers the following questions:
- What do you want to achieve?
- How do you attempt to achieve it? Reproducer: command line, input, ...
- What was the expected outcome?
- What was the actual outcome?
- What is the suggested change?

So with the more than Spartan information you provided, there is not
even the slightest evidence that there is a bug in 'ls' at all.
Therefore, I'm marking this as such in our bug tracker.
Of course, the discussion may continue here, and we may reopen
this issue once you have provided more information, and it really
turns out that there is a bug in the coreutils software.

Have a nice day,
Berny

bug#44959: date error message should say -I

[Bernhard Voelker]

Hi Padraig,

On 11/30/20 10:31 PM, Pádraig Brady wrote:
> For my reference, if we were to give explicit diagnosis of the leading '='.
> we would need to update xstrtol_fatal, XARGMATCH, operand2sig, set_fields, ...

I'd also rather keep it like it is, but if we change something:
we could advance past the '=' character in the option arg value
... at least in the case where only enumeration or numeric values
are expected (which obviously aren't too many).

Have a nice day,
Berny

bug#44959: date error message should say -I

[Bernhard Voelker]

On 11/30/20 2:13 PM, 積丹尼 Dan Jacobson wrote:
> $ date -I=seconds
> date: invalid argument ‘=seconds’ for ‘--iso-8601’

Hmm, first of all, 'date' 8.32 outputs more than the above:

  $ date -I=seconds
  date: invalid argument '=seconds' for '--iso-8601'
  Valid arguments are:
- 'hours'
- 'minutes'
- 'date'
- 'seconds'
- 'ns'
  Try 'date --help' for more information.

> Hey, that is a valid argument for --iso-8601. (But not for -I, so say
> that instead.)
...
> date (GNU coreutils) 8.32

>From the above error message and from the --help output, one can see that
the -I option does not require the argument to be appended with "=FMT" but
just "FMT":

  $ date --help | grep -- -I
-I[FMT], --iso-8601[=FMT]  output date/time in ISO 8601 format.

So, I'd say 'date' works as expected:

  $ date -Iseconds
  2020-11-30T14:38:35+01:00

Have a nice day,
Berny

bug#44763: Error when 'make'ing latest version of coreutils

[Bernhard Voelker]

[adding Paul]

On 11/21/20 8:54 PM, Chris Elvidge wrote:
>CC   test-nl_langinfo-mt.o
> test-nl_langinfo-mt.c: In function 'threadN_func':
> test-nl_langinfo-mt.c:185:1: error: no return statement in function 
> returning non-void [-Werror=return-type]
>   }
>   ^
> cc1: all warnings being treated as errors
> Makefile:6586: recipe for target 'test-nl_langinfo-mt.o' failed

I see the same with gcc-10.2.1 here.

It happens since:
  https://git.sv.gnu.org/cgit/gnulib.git/commit/?id=bd90572c031

Paul removed the return statement because Sun C 5.9 complains about it.

  static void *
  threadN_func (void *arg)
  {
for (;;)
  {
nl_langinfo (CODESET);   /* LC_CTYPE *//* locale charmap */
nl_langinfo (AM_STR);/* LC_TIME */ /* locale -k am_pm */
nl_langinfo (PM_STR);/* LC_TIME */ /* locale -k am_pm */
nl_langinfo (DAY_2); /* LC_TIME */ /* locale -k day */
nl_langinfo (DAY_5); /* LC_TIME */ /* locale -k day */
nl_langinfo (ALTMON_2);  /* LC_TIME */ /* locale -k alt_mon */
nl_langinfo (ALTMON_9);  /* LC_TIME */ /* locale -k alt_mon */
nl_langinfo (CRNCYSTR);  /* LC_MONETARY */ /* locale -k currency_symbol 
*/
nl_langinfo (RADIXCHAR); /* LC_NUMERIC */  /* locale -k decimal_point */
nl_langinfo (THOUSEP);   /* LC_NUMERIC */  /* locale -k thousands_sep */
  }

/*NOTREACHED*/
-   return NULL;
  }

How to fix?

Have a nice day,
Berny

bug#44763: Error when 'make'ing latest version of coreutils

[Bernhard Voelker]

On 11/20/20 5:38 PM, Chris Elvidge wrote:
> Reran the whole thing from git clone etc.
> (
> git clone git://git.sv.gnu.org/coreutils
> cd coreutils
> ./bootstrap
> git submodule foreach git pull origin master
> git config --global user.email "celvidge...@gmail.com"
> git config --global user.name "Chris Elvidge"
> git commit -m 'build: update gnulib submodule to latest' gnulib
> ./configure
> )

In general it is advised that one has to

 git clean -xdfq \
  && ./bootstrap

again after a gnulib update.

Have a nice day,
Berny

bug#44704: uniq: replace repeated lines with a message about how many repeated lines

[Bernhard Voelker]

On 11/18/20 12:25 PM, Chris Elvidge wrote:
> You could write your own function to do it. E.g.
> 
> unique() {
> [ "$1" ] || { echo "Needs a readable file to test" && return 1; }
> [ -r "$1" ] || { echo "Needs a readable file to test" && return 1; }
> R=""; N=0
> while IFS=$'\n' read L; do
> [ "$L" = "$R" ] && { ((N++)); continue; }
> [ "$N" -gt 0 ] && { echo "[Previous line repeated $N times]"; N=0; }
> R="$L"
> echo "$L"
> done <$1
> }

Nice.

The UNIX toolbox is diverse. ;-)
I'd use:

awk '
  function p(n) {
if (n > 1) {
  printf("[previous line repeated %d times]\n", n-1);
}
  }
  {
if (line != $0) {
  p(n);
  n = 0;
}
line = $0;
if (n == 0)
  print
n++;
  }
  END { p(n); }
'

Have a nice day,
Berny

bug#44635: bugs in watch

[Bernhard Voelker]

tag 44635 notabug
close 44635
stop

On 11/14/20 2:07 PM, John Lawrence Aspden wrote:
> Hi Guys,
> 
> I noticed a couple of things that look like bugs in 'watch' [...]

You have reached the GNU coreutils mailing list, and 'watch' is not part
of the coreutils [1].

[1] https://www.gnu.org/software/coreutils/

Instead, 'watch' is part of the 'procps' package (at least least on my system),
so you're better off asking on their mailing list, bug tracker, or whatever
they are using [2][3].

[2] https://gitlab.com/procps-ng/procps
[3] https://gitlab.com/procps-ng/procps/blob/master/Documentation/bugs.md

I'm therefore marking this as "not a bug" + "closed" in our bug tracker.

Have a nice day,
Berny

bug#44587: ls prints garbage when listing contents of a directory without exec permissions

[Bernhard Voelker]

On 11/12/20 12:24 AM, Jan Schaumann wrote:
> When running 'ls -l' on a directory that the user does
> not have execute permissions on, ls(1) still attempts
> to generate the long listing and prints the various
> fields with garbage:
> 
> $ mkdir dir
> $ touch dir/file
> $ chmod a-x dir
> $ ls -ld dir
> drw-r--r-- 2 jschauma users 28 Nov 11 23:15 dir
> $ ls -la dir
> ls: cannot access dir/.: Permission denied
> ls: cannot access dir/..: Permission denied
> ls: cannot access dir/file: Permission denied
> total 0
> d? ? ? ? ?? .
> d? ? ? ? ?? ..
> -? ? ? ? ?? file
> $ 
> 
> 
> Expected output:
> 
> $ ls -la dir
> ls: cannot access dir/.: Permission denied
> ls: cannot access dir/..: Permission denied
> ls: cannot access dir/file: Permission denied
> $ 
> 
> This is coreutils-8.32.

That feature seems to have been turned on explicitly in version 6.0 (in 2006):

https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=ccb1883fcd2

  [...] Apply the stat-failed parts of Red Hat's
  coreutils-selinux.patch.  From Ulrich Drepper.

  This makes it so files not mentioned on the command line (e.g.,
  names read from a directory that *is* mentioned on the command
  line) for which stat fails are still listed. [...]

Have a nice day,
Berny

bug#44412: RFE for 'env'?

[Bernhard Voelker]

tag 44412 notabug
close 44412
stop

On 11/3/20 6:29 PM, L A Walsh wrote:
> 
> 
> On 2020/11/03 04:29, Bernhard Voelker wrote:
>>
>> As you didn't give an example, it's hard for me to imagine what you
>> want to achieve, or better why current 'env' would "dislike it".
> ---
>   I tried to use 'env' to find perl in my path and wanted to pass
> the -T option to perl.
> 
> /usr/bin/env perl -T
> 
> print "Hello World\n";
> 
> Couldn't figure out anyway to have env look up my program in my path and
> to pass an option to that program.

Thanks, so it seems 'env' works as expected and supports the way you need
it to run.  Therefore, I'm marking this as not a bug in the bug tracker.
Of course, discussion may continue if needed.

Have a nice day,
Berny

bug#44412: RFE for 'env'?

[Bernhard Voelker]

On 11/3/20 10:14 AM, L A Walsh wrote:
> I wanted to pass a switch to an interp line, but 'env' seems to dislike it.
> 
> I also noticed that env ignores '--' to indicate end of switches that it 
> should
> process.
> 
> How difficult would this be to do? Specifically,
> allow double-dash ("--") to indicate the end of 'env' switches such
> that any following arguments would be passed to program to be run?
> 
> I was surprised when I found out it didn't do this.
> 
> Thanks!

As you didn't give an example, it's hard for me to imagine what you
want to achieve, or better why current 'env' would "dislike it".

I mean, passing an environment variable starting with a minus already
works by using "--" as an option separator:

  $ env --chdir=/tmp -- -KEY=VAL printenv  -- -KEY
  VAL

What did I miss?

Have a nice day,
Berny

bug#43235: Xeoma Docker Container Bug reporting to GNU.org

[Bernhard Voelker]

tag 43235 notabug
close 43235
stop

On 2020-09-06 16:37, Philip Rowlands wrote:
> On Sun, 6 Sep 2020, at 06:08, Scott Carter wrote:
> 
>> *tail: unrecognized file system type 0x794c7630 for ‘/var/log/syslog’.
>> please report this to bug-coreutils@gnu.org .
> 
> Recent versions of tail now take this upstream source filesystem types from
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/magic.h
> 
> which I see includes
> #define OVERLAYFS_SUPER_MAGIC 0x794c7630
> 
> Thanks for the report, but as it's already fixed, you should ask whoever 
> provided that docker container to update it (currently 4 years old).

Indeed, overlayfs - commonly used with Docker containers - has been added
in version 8.25. We're currently at 8.32.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

I'm hereby closing this as not a bug in our bug tracker.

>> It loads and says there is an error and is running in Trial Mode.  What can
>> be done here??

>> *Found problems with activation. Xeoma will be launched in Trial mode*

Regarding this: this is not related with the error diagnostic from tail(1),
thus we can not help you here at the GNU coreutils mailing list.
Better report this at a Xeoma mailing list (or whatever their support channel 
is).

Have a nice day,
Berny

bug#42633: 8.32 make check as root failure of rmdir/ignore.sh

[Bernhard Voelker]

On 2020-07-31 21:42, Pádraig Brady wrote:
> Patch looks good thanks.

Thanks.

> An alternative could be to use rmdir itself to test, like:
> 
>if ! rmdir x/y 2>/dev/null; then
>  returns_ 1 rmdir --ignore-fail-on-non-empty x/y || fail=1
>fi

I thought about that, but as there's a second hunk to be guarded a couple
of lines later, we'd have to remember the result of the test in a variable,
and test for that there.  That's more code, so unless we're getting new
FPs on some platform, I'd go with the standard uid_is_privileged_ function.

Pushing soon ... unless there are objections.
Thanks again - also for testing, Nick.

Have a nice day,
Berny

bug#42633: 8.32 make check as root failure of rmdir/ignore.sh

[Bernhard Voelker]

On 2020-07-31 16:32, Nick Alcock wrote:
> I get an ERROR when running rmdir/ignore.sh as root (but not when
> running as non-root). [...]

> ERROR: tests/rmdir/ignore
> =
[...]
> + mkdir -p x/y
> + chmod a-w x
> + returns_ 1 rmdir --ignore-fail-on-non-empty x/y
> + fail=1

Thanks for reporting this issue.

Indeed, this test does not work as root.
The comment in the test explains that it expects an EPERM error:

  # Ensure that with --ignore-fail-on-non-empty, we still fail, e.g., for EPERM.
  # Between 6.11 and 8.31, the following rmdir would mistakenly succeed.
  mkdir -p x/y || framework_failure_
  chmod a-w x || framework_failure_
  returns_ 1 rmdir --ignore-fail-on-non-empty x/y || fail=1

but root does not see the EPERM; strace output:

  ...
  rmdir("x/y")= 0
  close(1)= 0
  close(2)= 0
  exit_group(0)   = ?
  +++ exited with 0 +++

The attached patch adds guards around the parts of the test which
only work as non-privileged user.

Have a nice day,
Berny
>From c0e5f8c59b951ae13ca9cb9945cd77163489e1d9 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Fri, 31 Jul 2020 19:49:35 +0200
Subject: [PATCH] tests: skip some parts of 'tests/rmdir/ignore.sh' if run as
 root

Parts of this test expect that the rmdir syscall returns with EPERM,
but the root user does not see that.

* tests/rmdir/ignore.sh: Add uid_is_privileged_ guards around parts
of the test which expect rmdir() to fail with EPERM.

Reported by Nick Alcock  in
https://bugs.gnu.org/42633
---
 tests/rmdir/ignore.sh | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/tests/rmdir/ignore.sh b/tests/rmdir/ignore.sh
index 65e92d012..b26ac533a 100755
--- a/tests/rmdir/ignore.sh
+++ b/tests/rmdir/ignore.sh
@@ -33,17 +33,24 @@ test -d "$cwd/a/b/c" && fail=1
 # Between 6.11 and 8.31, the following rmdir would mistakenly succeed.
 mkdir -p x/y || framework_failure_
 chmod a-w x || framework_failure_
-returns_ 1 rmdir --ignore-fail-on-non-empty x/y || fail=1
+
+if ! uid_is_privileged_; then  # root does not get EPERM.
+  returns_ 1 rmdir --ignore-fail-on-non-empty x/y || fail=1
+fi
+
 test -d x/y || fail=1
 # Between 6.11 and 8.31, the following rmdir would mistakenly fail,
 # and also give a non descript error
 touch x/y/z || framework_failure_
 rmdir --ignore-fail-on-non-empty x/y || fail=1
 test -d x/y || fail=1
-# assume empty dir if unreadable entries (so failure to remove diagnosed)
-rm x/y/z || framework_failure_
-chmod a-r x/y || framework_failure_
-returns_ 1 rmdir --ignore-fail-on-non-empty x/y || fail=1
-test -d x/y || fail=1
+
+if ! uid_is_privileged_; then  # root does not get EPERM.
+  # assume empty dir if unreadable entries (so failure to remove diagnosed)
+  rm x/y/z || framework_failure_
+  chmod a-r x/y || framework_failure_
+  returns_ 1 rmdir --ignore-fail-on-non-empty x/y || fail=1
+  test -d x/y || fail=1
+fi
 
 Exit $fail
-- 
2.27.0

bug#41634: 'timeout' returning 124 and 133

[Bernhard Voelker]

On 2020-07-28 23:53, Pádraig Brady wrote:
> +1 thanks

Thanks, pushed.

bug#41634: 'timeout' returning 124 and 133

[Bernhard Voelker]

On 2020-07-16 00:59, Jonny Grant wrote:
> On 15/06/2020 21:57, Bernhard Voelker wrote:
>> Hmm, in the HTML format, this is the first sentence after the table of 
>> contents:
>>
>>   "This manual documents version 8.32 of the GNU core utilities, ..."
> 
> Hi Berny
> Just to reply on this item.
> 
> Ah ok, on the HTML page that is still 12 pages after the first page. It would 
> be nice to see it below the title? Before the TOC.
> https://www.gnu.org/software/coreutils/manual/coreutils.html
> 
> I didn't search through for the version number, I missed it, as it wasn't at 
> the top, or at the end.

The attached adds the version to the title of the HTML manual.
E.g. grep also has it:
  https://www.gnu.org/software/grep/manual/html_node/index.html

@Padraig: okay to push?

Have a nice day,
Berny
>From 881c3f20ec435a9c57390853483942fa1101c32b Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Tue, 28 Jul 2020 23:28:45 +0200
Subject: [PATCH] doc: show version in title of HTML manual

* doc/coreutils.texi (@include version.texi): Move before ...
(@settitle): ... this.  Add the version after the package name.

Suggested by Jonny Grant  in
https://lists.gnu.org/r/bug-coreutils/2020-07/msg00021.html
---
 doc/coreutils.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index bebccbcb6..52d4cfcbe 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -1,13 +1,13 @@
 \input texinfo
 @c %**start of header
 @setfilename coreutils.info
-@settitle GNU Coreutils
+@include version.texi
+@settitle GNU Coreutils @value{VERSION}
 @documentencoding UTF-8
 @allowcodebreaks false
 
 @c %**end of header
 
-@include version.texi
 @include constants.texi
 
 @c Define new indices.
-- 
2.27.0

bug#42470: Help text update suggestion for "date" util

[Bernhard Voelker]

[sorry, this one hung in my outbox ... not sure if this helps though]

On 2020-07-25 17:07, Wes Novack wrote:
> For future reference, what is the PR process?

Not exactly sure what you mean with "PR".
If you refer to the process of reporting bugs, making suggestions, sending
patches, etc., then please refer to the corresponding sections at:
  https://www.gnu.org/software/coreutils/

If PR is meant as "(git) pull request": just plain patches are sent
to the mailing list(s). Please see:
  https://git.savannah.gnu.org/cgit/coreutils.git/tree/README-hacking

Have a nice day,
Berny

bug#42470: Help text update suggestion for "date" util

[Bernhard Voelker]

On 2020-07-21 19:45, Wes Novack wrote:
> Greetings! For the GNU coreutils "date" utility, I would like to suggest
> updating the help text
> 
> from %s seconds since 1970-01-01 00:00:00 UTC
> to %s seconds since the epoch, 1970-01-01 00:00:00 UTC
> 
> This was suggested in this StackOverflow post and has received many (45)
> upvotes.
> https://stackoverflow.com/questions/1092631/get-current-time-in-seconds-since-the-epoch-on-linux-bash#comment10059260_1092643
> 
> Would you consider this update?

Thanks for the suggestion.

Paul fixed it with this commit:
  https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=fa7a5074d7

Marking this as done.

Have a nice day,
Berny

bug#41634: 'timeout' returning 124 and 133

[Bernhard Voelker]

On 2020-07-05 12:53, Jonny Grant wrote:
> Your patch looks great.

Thanks, pushed (with the minor tweak mentioned below) at:
  https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=49bd08aea

> Is it worth clarifying that --kill-after=0s would send the KILL signal 
> immediately after TERM?
> $ timeout --kill-after=0s 2s du -h

As the signal handler for the regular signal (TERM) does probably not have
enough time to do anything before being KILLed, this use case would better
be written as:

  $ timeout -s KILL 2s du -h

Not sure this is worth an extra explanation.

> Is it worth rejecting this? At the moment the -k is just ignored.
> $ timeout -k 2s 0s du -h

Hmm, rejecting is a bit harsh.  The question is if this is really
a problem for the users?  I mean once a user knows there is a -k
option, I would expect that she has read the documentation about
how to use it.
It is mentioned both in the Texinfo manual and in the --help output:

  A duration of 0 disables the associated timeout.

I squashed in the following little change:

  -This option has no effect if @command{timeout}'s duration is 0 and therefore
  +This option has no effect if @command{timeout}'s duration is 0 which
   disables the associated timeout.

Have a nice day,
Berny

bug#41634: 'timeout' returning 124 and 133

[Bernhard Voelker]

On 2020-07-04 00:57, Jonny Grant wrote:
> May I ask if that exit status 137 could be clarified as 128+9, where 9 is
> the KILL signal number in this example please. I've pasted a patch below.

Thanks for the patch - this is always a great basis for discussions.

Well, this 128+9 arithmetic is explained just a couple of lines above,
i.e., where all the value for the exit status are described.
So adding it here again looks like repetition to me.

> Another question, for me it wasn't clear that the "-k 3s" was cumulative
> with the duration 5, so the total being 8. I thought both durations
> both counted from when the command was invoked.
> 
> https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html#timeout-invocation
> ‘-k duration’
> ‘--kill-after=duration’
> Ensure the monitored command is killed by also sending a ‘KILL’ signal,
> after the specified duration. Without this option, if the selected signal
> proves not to be fatal, timeout does not kill the command.
> 
> Could this be clarified as "after the existing duration is added to
> this specified duration, cumulatively from when the command is invoked."?
> I can make another patch if this would be fine, and my understanding is 
> correct.

Good catch, this is only documented in --help output (and therefore in 
timeout.1):

  -k, --kill-after=DURATION
 also send a KILL signal if COMMAND is still running
   this long after the initial signal was sent

What about the attached?

Thanks & have a nice day,
Berny
>From 56e4aa9d0c083b9e49747d51866e80acec1142a2 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Sun, 5 Jul 2020 01:20:10 +0200
Subject: [PATCH] doc: clarify 'timeout -k' behavior

* doc/coreutils.texi (timeout invocation): Document that the the
duration of --kill-after=DURATION begins when sending the initial
signal.  Also mention that -k does not have any effect if timeout's
duration is 0.

Suggested by Jonny Grant .
---
 doc/coreutils.texi | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index c072b1575..80ca2858c 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -18108,9 +18108,19 @@ themselves (like GDB for example).
 @opindex -k
 @opindex --kill-after
 Ensure the monitored @var{command} is killed by also sending a @samp{KILL}
-signal, after the specified @var{duration}.  Without this option, if the
-selected signal proves not to be fatal, @command{timeout} does not kill
-the @var{command}.
+signal.
+
+The specified @var{duration} starts from the point in time when
+@command{timeout} sends the initial signal to @var{command}, i.e.,
+not from the beginning when the @var{command} is started.
+
+This option has no effect if @command{timeout}'s duration is 0 and therefore
+disables the associated timeout.
+
+This option may be useful if the selected signal did not kill the @var{command},
+either because the signal was blocked or ignored, or if the @var{command} takes
+too long (e.g. for cleanup work) to terminate itself within a certain amount
+of time.
 
 @item -s @var{signal}
 @itemx --signal=@var{signal}
-- 
2.27.0

bug#41634: 'timeout' returning 124 and 133

[Bernhard Voelker]

On 2020-06-15 22:57, Bernhard Voelker wrote:
> The attached is an attempt to add some useful examples.

There were no comments, so I pushed with a few tweaks:
  https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=b1c6ef230c

Marking this as done.

Have a nice day,
Berny

bug#41935: tail: unrecognized file system type 0x786f4256

[Bernhard Voelker]

marking this as done.

bug#41935: tail: unrecognized file system type 0x786f4256

[Bernhard Voelker]

On 2020-06-20 19:28, Pádraig Brady wrote:
> +1

Thanks for the review, pushed at:
https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=f5644c986ce

Have a nice day,
Berny

bug#41935: tail: unrecognized file system type 0x786f4256

[Bernhard Voelker]

On 2020-06-18 17:57, Pausch Manfred wrote:
> Hello
> 
> When I tail a logfile that’s located on a VirtualBox guest shared folder than 
> I get this message:
> 
> tail: unrecognized file system type 0x786f4256 for 
> ‘oracle_12102_PSU190716-20200618_174315.log’. please report this to 
> bug-coreutils@gnu.org. reverting to polling
> 
> My setup:
> VirtualBox Guest: Oracle Linux 7.x
> VirtualBox Host: Windows 10
> 
> A directory on the host is mapped into the guest via VirtualBox shared folder 
> and mounted in the guest.
> The process that writes to the logfile runs inside the guest. And tail that 
> follows the logfile also runs inside the guest.

Thanks for the report.
It's unusual that this FS-type slipped through for so long.
The attached fixes it.

An internet search unveils that inotify does not seem to work reliably
for 'vboxsf', and I think that this cannot really reliably work, e.g. if a 
Windows
host exposes a directory on a CIFS share into a Linux guest VM (which works, I 
tried).
Therefore, I've marked 'vboxsf' as a 'remote' file system which uses polling.

Have a nice day,
Berny
>From f5644c986ce39c6ca5fffbae30a2828b8ee56502 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Fri, 19 Jun 2020 20:33:55 +0200
Subject: [PATCH] stat,tail: add support for the VBOXSF file system

* src/stat.c (human_fstype): Add case for the 'vboxsf' file system type
which is used for VirtualBox Shared Folders mounted in VirtualBox guest
VMs.
* NEWS: Mention the Improvement.
Fixes https://bugs.gnu.org/41935
---
 NEWS   | 5 +
 src/stat.c | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/NEWS b/NEWS
index 655ff779f..d36259641 100644
--- a/NEWS
+++ b/NEWS
@@ -26,6 +26,11 @@ GNU coreutils NEWS-*- outline -*-
ls --classify now supports the "always", "auto", or "never" flags,
to support only outputting classifier characters if connected to a tty.
 
+** Improvements
+
+  stat and tail now know about the "vboxsf" file system type.
+  stat -f -c%T now reports the file system type, and tail -f uses polling.
+
 
 * Noteworthy changes in release 8.32 (2020-03-05) [stable]
 
diff --git a/src/stat.c b/src/stat.c
index 5012622c3..4e6c2aa86 100644
--- a/src/stat.c
+++ b/src/stat.c
@@ -527,6 +527,8 @@ human_fstype (STRUCT_STATVFS const *statfsbuf)
   return "usbdevfs";
 case S_MAGIC_V9FS: /* 0x01021997 local */
   return "v9fs";
+case S_MAGIC_VBOXSF: /* 0x786F4256 remote */
+  return "vboxsf";
 case S_MAGIC_VMHGFS: /* 0xBACBACBC remote */
   return "vmhgfs";
 case S_MAGIC_VXFS: /* 0xA501FCF5 remote */
-- 
2.27.0

bug#41850: [PATCH] maint: Avoid signed integer overflows

[Bernhard Voelker]

On 2020-06-16 00:11, Pádraig Brady wrote:
> I've updated your patch (attached) to add tests for this.

nice, thanks.

Have a nice day,
Berny

bug#41634: 'timeout' returning 124 and 133

[Bernhard Voelker]

Hi Jonny,

On 2020-06-07 18:04, Jonny Grant wrote:
> Hi Berny
> 
> Sorry I was meaning to give an example of a shell command to send KILL, but 
> maybe it's not necessary.
> 
> BTW, I saw the patch was applied. Great it's improved
> 
> 
> I saw this new line is clearer:
> "Upon timeout, send the TERM signal to COMMAND, if no other SIGNAL specified."
> 
> However, I thought even clearer is this variation :-
> "Upon timeout, if no SIGNAL specified by --signal, send the TERM signal to 
> COMMAND."

IMO this is not really correct, as it states that a signal - TERM - is (only?)
sent in the case when --signal was not used, i.e., what happens in "else"?
It's hard to write short and precise man documentation.

> May I ask, do these texinfo changes also go into the man page?

No, at GNU coreutils (and lots of other GNU projects in general), we intend
to have small man pages, and leave the more detailed information in the
Texinfo manual:
  https://www.gnu.org/prep/standards/html_node/Man-Pages.html

Actually, the coreutils man pages are generated by running the tools with 
--help,
with some tiny information augmented where useful.

> This is the man page 8.32, and it doesn't match the html manual
> https://www.man7.org/linux/man-pages/man1/timeout.1.html

The man page project collects the latest version after a release.

> I'm looking at the generated html manual:
> https://www.gnu.org/software/coreutils/manual/coreutils.html#timeout-invocation

This belongs to the GNU coreutils project and will be updated with the
next release.

> I don't know if these html pages can be updated to show the coreutil version 
> on them at all at the top oand bottom?

Hmm, in the HTML format, this is the first sentence after the table of contents:

  "This manual documents version 8.32 of the GNU core utilities, ..."

In the info reader (`info coreutils`), this is even the first sentence.
It's also on the title page of the generated PDF documentation.

> Could an example be given on the man page and manual?

As said, we wouldn't add such examples to the man page, I'm afraid ...

> ===
> EXAMPLE
> 
> The command below gives an example to demonstrate the use of this, sending 
> HUP  signal after 5 seconds, and sending the 
> KILL signal after 10 seconds if 'ls' has not finished.
>  $ timeout -k 10s -s HUP 5s ls
> ===
... but for sure in the Texinfo manual.
The attached is an attempt to add some useful examples.

> My last question
> 
> There is -k, it would be clearer if it was possible to specify -t or 
> --timeout,
> "$ timeout -k 11s 6s ls"   This always looks ambiguous to me, but the 11s is 
> the KILL, and the 6s is the regular TERM 
> signal.
> 
> Would you consider supporting a -t ?
> So then we could write
> "$ timeout -t 6s -k 11s ls"
> 
> or even
> "$ timeout --timeout=6s --kill-after=11s ls"

While that would be possible, I'm not so excited about it.
The timeout value is a mandatory value similar to the perms for chmod(1),
and I've not seen any requests to support "chmod --mode=MODE FILE".

Have a nice day,
Berny
>From 33870a01ef65145ccc0cc7f0bf0b76cafec9d95d Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Mon, 15 Jun 2020 22:47:15 +0200
Subject: [PATCH] doc: add timeout examples

* doc/coreutils.texi (timeout invocation): Add examples.

Suggested by Jonny Grant  in
https://lists.gnu.org/r/bug-coreutils/2020-06/msg00018.html
---
 doc/coreutils.texi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 3432fb294..4f6c6129b 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -18153,6 +18153,28 @@ or to @command{timeout} itself, i.e., these cases cannot be distinguished.
 In the latter case, the @var{command} process may still be alive after
 @command{timeout} has forcefully been terminated.
 
+Examples:
+
+@example
+# Send the default TERM signal after 20s to a shorter-living 'sleep' command.
+# As that terminates with exit status 0 after 1s, 'timeout' returns the same.
+timeout 20 sleep 1
+
+# Send a INT signal after 5s to the 'sleep' command.  Returns after 5 seconds
+# with exit status 124 to indicate the sending of the signal.
+timeout -s INT 5 sleep 20
+
+# Likewise, but ignoring the signal via 'env --ignore-signal'.
+# Thus, 'sleep' terminates regularly after the full 20 seconds,
+# still 'timeout' returns with exit status 124.
+timeout -s INT 5s env --ignore-signal=INT sleep 20
+
+# Likewise, but sending another KILL signal 3 seconds after the initial INT.
+# Here, 'sleep' is forcefully terminated after about 8 seconds (5+3),
+# and 'timeout' returns with an exit status of 137.
+timeout -s INT -k 3s 5s env --ignore-signal=INT sleep 20
+@end example
+
 @node Process control
 @chapter Process control
 
-- 
2.27.0

bug#41792: dd function – message: "No boot sector on USB device""

[Bernhard Voelker]

tag 41792 notabug
close 41792
stop

response below...

On 2020-06-10 17:49, Ricky Tigg wrote:
> *Component*: coreutils.x86_64  8.32-4.fc32.; *OS*: Linux Fedora
> 
> Source of file:
> https://www.microsoft.com/en-us/software-download/windows10ISO
> 
> Disc image file
> - checked against its SHA-256 checksum was correct
> - written successfully with that command:
> # dd if=Win10_2004_Finnish_x64.iso of=/dev/sdc bs=4M oflag=direct
_^^^

> status=progress && sync
> 
> Once written, the partition is as follows:
> $ mount | fgrep /run/media/$USER
> /dev/sdb on /run/media/yk/CCCOMA_X64FRE_FI-FI_DV9 type udf
___^^^
> (ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,uhelper=udisks2)

sdc vs. sdb?
You wrote to a different disk.

Apart from that, there's not proof that this problem is related to dd(1).
As such, I'm marking this as "not a bug" in our bug tracker.  However. the
discussion can of course continue, and we could even re-open the issue once
it would - unlikely - turn out to be a dd(1) bug.

Have a nice day,
Berny

bug#41634: 'timeout' returning 124 and 133

[Bernhard Voelker]

On 2020-06-07 15:34, Pádraig Brady wrote:
> [...] it is better to add the comma there [...]

thanks, pushed with that change:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=189776ff3b

Marking this as done.

Have a nice day,
Berny

bug#41634: 'timeout' returning 124 and 133

[Bernhard Voelker]

Hi Padraig,

On 2020-06-07 14:13, Pádraig Brady wrote:
> How about we add the exit code table to the man page also?
> I've adjusted your patch to do that (along with some other tweaks) in the 
> attached.

nice, especially also:

> -124 if @var{command} times out
> +124 if @var{command} times out, and @option{--preserve-status} is not 
> specified

Minor, grammar-related question:

> +Upon timeout send the TERM signal to COMMAND, if no other SIGNAL 
> specified.\n\
___^
s/timeout/&,/ ?

I stumbled upon this sentence a couple of times - shouldn't there be a comma?
The word 'timeout' could be a regular noun, a verb, or in this special case
the name of the tool, so I had to read the first half several times.
But maybe it's only me as a non-native English speaker - commas are much
cheaper over here. ;-)

Thanks & have a nice day,
Berny

bug#41634: 'timeout' returning 124 and 133

[Bernhard Voelker]

On 2020-06-06 23:49, Jonny Grant wrote:
> Great patch.

thanks, Padraig meanwhile further improved it.

> How about writing signal 9 by the name, ie $ kill -s KILL
> likewise $ kill -s TERM

Where do you mean?

Have a nice day,
Berny

bug#41634: 'timeout' returning 124 and 133

[Bernhard Voelker]

On 2020-06-01 10:01, Jonny Grant wrote:
> My mistake missing that. But could the 137 be listed explicitly?
> ie.
> "It may be  necessary  to  use the KILL (9) signal, since this signal cannot 
> be caught, in which case the exit status is 
> 137 (128+9) rather than 124."

thanks for the suggestion.

I think this could still be improved:
there is still the open question what happens when the KILL signal
is sent either to timeout(1) or to COMMAND.
The attached patch tries to clarify.

Have a nice day,
Berny
>From d4ee1f8ace585124e80a3d6e11c6902e37e9e71f Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Sat, 6 Jun 2020 01:22:00 +0200
Subject: [PATCH] doc: timeout: further clarify exit status after KILL signal

* doc/coreutils.texi (timeout invocation): Document that the exit
status is 137 when the KILL signal is used, regardless of wether that
signal is sent to COMMAND or timeout.
* src/timeout.c (usage): Likewise.

Discussed at https://bugs.gnu.org/41634
---
 doc/coreutils.texi | 8 +++-
 src/timeout.c  | 6 +++---
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index f0684b1c5..07494ab0f 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -18143,10 +18143,16 @@ Exit status:
 125 if @command{timeout} itself fails
 126 if @var{command} is found but cannot be invoked
 127 if @var{command} cannot be found
-137 if @var{command} is sent the KILL(9) signal (128+9)
+137 if @var{command} or @command{timeout} is sent the KILL(9) signal (128+9)
 the exit status of @var{command} otherwise
 @end display
 
+In case of the @samp{KILL(9)} signal, @command{timeout} returns with
+exit status 137, regardless of whether that signal is sent to @var{command}
+or to @command{timeout} itself, i.e., these cases cannot be distinguished.
+In the latter case, the @var{command} process may still be alive after
+@command{timeout} has forcefully been terminated.
+
 
 @node Process control
 @chapter Process control
diff --git a/src/timeout.c b/src/timeout.c
index 14ae88da5..9e7cef8f9 100644
--- a/src/timeout.c
+++ b/src/timeout.c
@@ -272,9 +272,9 @@ DURATION is a floating point number with an optional suffix:\n\
 If the command times out, and --preserve-status is not set, then exit with\n\
 status 124.  Otherwise, exit with the status of COMMAND.  If no signal\n\
 is specified, send the TERM signal upon timeout.  The TERM signal kills\n\
-any process that does not block or catch that signal.  It may be necessary\n\
-to use the KILL (9) signal, since this signal cannot be caught, in which\n\
-case the exit status is 128+9 rather than 124.\n"), stdout);
+any process that does not block or catch that signal.\n\
+If the KILL (9) signal - which cannot be caught - is sent to COMMAND or\n\
+timeout, then the exit status is 137 (128+9) rather than 124.\n"), stdout);
   emit_ancillary_info (PROGRAM_NAME);
 }
   exit (status);
-- 
2.26.2

bug#37702: Suggestion for 'df' utility

[Bernhard Voelker]

On 2020-05-31 01:07, Paul Eggert wrote:
> On 5/30/20 4:49 AM, Erik Auerswald wrote:
>> I concur that a command line option to override config file (or env var)
>> settings seems useful if a config file and/or env var approach is used.

Just to mention another alternative to control the behavior besides env 
variables or
config files: it would theoretically also be possible to add a './configure' 
option
to add more file system types to the list of pseudofilesystems at build time.
Obviously, such idea moves the responsibility to the packager - which is not
nice either.

> In other utilities we've been moving away from environment variables and/or
> config files for the usual security and other-hassle reasons. So I'd prefer
> having 'df' just do the "right" thing by default, and to have an option to
> override that. The "right" thing should be to ignore all these 
> pseudofilesystems
> that hardly anybody cares about.

+1

What about to start with this?

  $ GIT_PAGER= git -C gnulib diff
  diff --git a/lib/mountlist.c b/lib/mountlist.c
  index 7abe0248e..5f6249dec 100644
  --- a/lib/mountlist.c
  +++ b/lib/mountlist.c
  @@ -164,6 +164,9 @@

   #define ME_DUMMY_0(Fs_name, Fs_type)\
 (strcmp (Fs_type, "autofs") == 0  \
  +   || strcmp (Fs_type, "tmpfs") == 0\
  +   || strcmp (Fs_type, "devtmpfs") == 0 \
  +   || strcmp (Fs_type, "squashfs") == 0 \
  || strcmp (Fs_type, "proc") == 0 \
  || strcmp (Fs_type, "subfs") == 0\
  /* for Linux 2.6/3.x */  \

Example output (here on openSUSE:Tumbleweed):

  $ src/df -Th
  Filesystem Type  Size  Used Avail Use% Mounted on
  /dev/sda2  ext4   20G   14G  5.1G  73% /
  /dev/sda5  ext4  591G  278G  313G  48% /media/big_data
  /dev/loop0 ext2   31M   31M 0 100% /FULL_PARTITION_TMPDIR
  /dev/sda3  ext3  109G   90G   14G  87% /home

... thus omitting those mounts:

  $ diff -wu0 <(/usr/bin/df -Th) <(src/df -Th)
  --- /dev/fd/632020-05-31 11:30:29.991664999 +0200
  +++ /dev/fd/622020-05-31 11:30:29.987664947 +0200
  @@ -2,4 +1,0 @@
  -devtmpfs   devtmpfs  9.8G  8.0K  9.8G   1% /dev
  -tmpfs  tmpfs 9.8G  640K  9.8G   1% /dev/shm
  -tmpfs  tmpfs 9.8G   18M  9.8G   1% /run
  -tmpfs  tmpfs 9.8G 0  9.8G   0% /sys/fs/cgroup
  @@ -10 +5,0 @@
  -tmpfs  tmpfs 2.0G   44K  2.0G   1% /run/user/1000

Have a nice day,
Berny

bug#41106: date --date '20180325 02:58:00' fails

[Bernhard Voelker]

tag 41106 notabug
thanks

On 2020-05-06 10:04, Julien Demaria wrote:
>> $ date --date '20180325 02:58:00'
>> date: invalid date `20180325 02:58:00'

> Sorry I just found the reason in the FAQ... :-(
> https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e
> I am in local daylight saving time change case.

Indeed, the debug option shows it:

date --debug --date '20180325 02:58:00'
date: parsed number part: (Y-M-D) 2018-03-25
date: parsed time part: 02:58:00
date: input timezone: system default
date: using specified time as starting value: '02:58:00'
date: error: invalid date/time value:
date: user provided time: '(Y-M-D) 2018-03-25 02:58:00'
date:normalized time: '(Y-M-D) 2018-03-25 03:58:00'
date: --
date:  possible reasons:
date:non-existing due to daylight-saving time;
date:numeric values overflow;
date:missing timezone
date: invalid date '20180325 02:58:00'

As such, I'm marking this issue as 'notabug' in our bug tracker.

Have a nice day,
Berny

bug#40551: tail: unrecognized file system type 0x794c7630 for /path/to/nginx/error.log'

[Bernhard Voelker]

tag 40551 notabug
close 40551
stop

Hello,

On 2020-04-11 10:20, 王群强 wrote:
> hi ,
> I am using " tail -f error.log "  command in k8s pod environment, thus i
> got a fatal error bellow :
> 
>  error message ===
> tail: unrecognized file system type 0x794c7630 for 'error.log'. please
> report this to bug-coreutils@gnu.org. reverting to polling

This is not a fatal error, but rather a kind of warning message.

> = pod information==
> [root@xiaozh ]# uname -a
> Linux xiaozhx 3.10.0-1062.el7.x86_64 #1 SMP Wed Aug 7 18:08:02 UTC 2019
> x86_64 x86_64 x86_64 GNU/Linux
> 
> [root@xiaozh ]# cat /etc/centos-release
> CentOS Linux release 7.2.1511 (Core)

Next time, please also report the coreutils version.

overlayfs - commonly used with Docker containers - has been added
in version 8.25. Consider upgrading Coreutils if possible.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

Have a nice day,
Berny

bug#40352: cp -a --attributes-only zeroes a file with more than one link

[Bernhard Voelker]

On 2020-04-01 14:10, Pádraig Brady wrote:
> On 31/03/2020 13:32, Matt Kloss wrote:
>> Hello,
>>
>> When you cp -a --attributes-only a [dest] file which has a more than one
>> “hardlink”, it zeroes the file:
> 
> The attached fixes this, which I'll push later.
> Marking this as done.

LGTM, thanks!

Have a nice day,
Berny

bug#39951: tail -n +NUM is not working properly

[Bernhard Voelker]

On 3/6/20 10:42 AM, Dimitris Moraitidis wrote:

Hey there,

tail -n + NUM does not return the desired output. +NUM starts from the top
of the file, not from the bottom.

So for example, given the following file:


this
is
an
example
file
each
word
represents
a
line


and executing tail -n +3 example, I am getting


example
file
each
word
represents
a
line


instead of



this
is
an
example
file
each
word


I am using *tail (GNU coreutils) 8.28 *in latest ubuntu 18.04 LTS

Thanks in advance for looking into this :)


Isn't this exactly what tail(1) is support to do when the user explicitly
passes the '+' sign to the number?

  $ tail --help | grep -A1 -- --lines
-n, --lines=[+]NUM   output the last NUM lines, instead of the last 10;
   or use -n +NUM to output starting with line NUM

Also POSIX says so:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/tail.html

Have a nice day,
Berny

bug#39929: coreutils-8.32 fails to build on aarch64

[Bernhard Voelker]

On 2020-03-06 08:31, Bernhard Voelker wrote:
> On 2020-03-06 02:27, Paul Eggert wrote:
>> On 3/5/20 1:43 PM, Paul Eggert wrote:
>>
>>> Why is this code even there at all? If readdir(3) says that the current
>>> directory has no entries, shouldn't 'ls' just say that? Why should ls
>>> report an error simply because the current directory isn't reachable
>>> from the filesystem? Whether the current directory is unreachable has
>>> nothing to do with ls's job, which is to report whether the current
>>> directory has entries.
>>
>> Attached is a proposed patch to fix this.
> 
> I tend to agree (now): returning an error when there was none seems at least
> unlucky.  Sorry I didn't comment in the original discussion.
> 
>> diff --git a/tests/ls/removed-directory.sh b/tests/ls/removed-directory.sh
> 
> That test was also added in commit 05a99f7d7f8e, so the the description
> at the top does not match after reverting:
> 
>   #!/bin/sh
>   # If ls is asked to list a removed directory (e.g. the parent process's
>   # current working directory that has been removed by another process), it
>   # emits an error message.
> 
> s/emits/shall not emit/

P.S. Also the check for $host_triplet containing 'linux' in test is:
a) no longer needed, and
b) looks like a good argument to revert 05a99f7d7f8e, because it introduced
different (and user-visible) behavior just because of the platform.

Have a nice day,
Berny

bug#39929: coreutils-8.32 fails to build on aarch64

[Bernhard Voelker]

On 2020-03-06 02:27, Paul Eggert wrote:
> On 3/5/20 1:43 PM, Paul Eggert wrote:
>
>> Why is this code even there at all? If readdir(3) says that the current
>> directory has no entries, shouldn't 'ls' just say that? Why should ls
>> report an error simply because the current directory isn't reachable
>> from the filesystem? Whether the current directory is unreachable has
>> nothing to do with ls's job, which is to report whether the current
>> directory has entries.
>
> Attached is a proposed patch to fix this.

I tend to agree (now): returning an error when there was none seems at least
unlucky.  Sorry I didn't comment in the original discussion.

> diff --git a/tests/ls/removed-directory.sh b/tests/ls/removed-directory.sh

That test was also added in commit 05a99f7d7f8e, so the the description
at the top does not match after reverting:

  #!/bin/sh
  # If ls is asked to list a removed directory (e.g. the parent process's
  # current working directory that has been removed by another process), it
  # emits an error message.

s/emits/shall not emit/

Thanks & have a nice day,
Berny

bug#39486: 答复: bug#39486: Test fail of tests/misc/env-S.pl and tests/misc/tty

[Bernhard Voelker]

[re-adding 39...@debbugs.gnu.org]

On 2/10/20 8:44 AM, ZJU wrote:

Thank you for your apply.
1. When i run make check under the building root, the result of test suit
failed two. The failure and the test suite log is the same of coreutils 8.30
and 8.31.
This problem I ran the test with non-root user. I want to know if there is any
reason that could caused the failure.
Thank you.


Without knowing more about your environment, it is a bit hard to
judge where the failures come from.

As a see an 'abuild' user, you might use the OpenBuildSystem like the openSUSE
project uses [1], and you seem to build with the --enable-single-binary option
of the './configure' script.  That should work (see [1]).

[1] https://build.opensuse.org/package/show/Base:System/coreutils

Please describe your build setup a bit more, so we could eventually reproduce
the issue on a similar setup.

Thanks & have a nice day,
Berny

bug#39486: Test fail of tests/misc/env-S.pl and tests/misc/tty

[Bernhard Voelker]

On 2020-02-07 16:23, ZJU wrote:
> 2. When i run the test suit as root, there were about 12 failures, dose the
> root influence the test suit? 

Indeed, the regular tests ('make check') are not intended to be run as 'root'.
Instead, there are several tests which are, and the best way to start those
is documented in the README file:

  sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root

Have a nice day,
Berny

bug#39364: [PATCH] rmdir: fix clobbered errno

[Bernhard Voelker]

On 2020-02-07 14:58, Pádraig Brady wrote:
> Yes the existing is_empty_dir() interface didn't change.
> We just added more info (errno) in the non empty case,
> that is not inspected by remove.c (which is fine for its uses).

Thanks for checking.

Have a nice day,
Berny

bug#39364: [PATCH] rmdir: fix clobbered errno

[Bernhard Voelker]

On 2020-02-04 20:21, Pádraig Brady wrote:
> pushed. marking done

Hi Padraig,

I just noticed that 'is_empty_dir' from 'src/system.h' is also used
in 'src/remove.c', so - without having looked there yet - it could
be that the patch changed something in rm(1) as well (good or bad).
Did you check?

Thanks & have a nice day,
Berny

bug#39135: Globbing with numbers does not allow me to specify order

[Bernhard Voelker]

tag 39135 notabug
close 39135
stop

On 2020-01-14 09:44, Antti Savolainen wrote:
> When doing a shortcut to unmount in a specific order, I am unable to
> specify order with angle brackets. For example using 'umount /dev/sda[132]'
> will result in the system unmounting them in numerological order. First 1
> then 2 and finally 3. What I need it to do is to first unmount 1, then 3
> and finally 2. It would be nice for the glob to respect the order of
> numbers that it was given.

Thanks for the report, but you reached the GNU coreutils mailing list
while umount is part of util-linux, and the globbing you're referring to
is done by your shell.

Therefore, you're better off asking at the mailing lists of those packages.
As this is not a bug in coreutils, I'm marking it as such, and close this
issue in our bug tracker.

A little hint:
if your shell knows brace expansion "{...}", then you could use that
instead of file globbing with "[...]".  The following does this with
'echo' put in front of the command in order to see what would be
executed:

  $ echo umount /dev/sda{1,3,2}
  umount /dev/sda1 /dev/sda3 /dev/sda2

Have a nice day,
Berny

bug#39092: Bug in coreutils "du"? - ignores files when both a file and a hard link is given

[Bernhard Voelker]

tag 39092 notabug
close 39092
stop

I had to take out your email address to be able to reply to this issue:

  An error occurred while sending mail. The mail server responded:
  Requested action not taken: mailbox unavailable
  invalid DNS MX or A/ resource record.
  Please check the message recipient "m...@rakul.info" and try again.

On 2020-01-11 18:23, Alex wrote:
> Hi guys,
> 
> I noticed that when I explicitly specify a file and a hardlink to that 
> file as du's command line arguments it ignores both of them. Here 
> "kernel", "initramfs" and "System.map" are hardlinks to 
> kernel-genkernel-x86_64-5.4.2-gentoo, 
> initramfs-genkernel-x86_64-5.4.2-gentoo and System.map-5.4.10-gentoo-x86_64.
> 
> 
> 19:56:45 [0] ~ >ls -la /boot/
> total 72281
> drwxr-xr-x  5 root root 1024 Jan 11 19:49 .
> drwxr-xr-x 22 root root 4096 Dec  7 21:00 ..
> -rw-r--r--  1 root root    0 Jan  8 23:58 .e.mount
> -rw-r--r--  1 root root    0 Jan  8 23:58 .keep
> -rw-r--r--  2 root root  3456397 Jan  9 21:48 System.map
> -rw-r--r--  1 root root  3474911 Dec  6 20:22 System.map-5.3.5-gentoo-x86_64
> -rw-r--r--  1 root root  3473259 Jan 11 19:49 
> System.map-5.4.10-gentoo-x86_64
> -rw-r--r--  2 root root  3456397 Jan  9 21:48 
> System.map-genkernel-x86_64-5.4.2-gentoo
> drwxr-xr-x  2 root root 1024 Apr 29  2019 efi
> drwxr-xr-x  7 root root 1024 Jan  9 22:50 grub
> -rw-r--r--  2 root root  8196820 Jan  9 22:15 initramfs
> -rw-r--r--  1 root root 16531780 Oct  9 21:35 
> initramfs-5.3.5-gentoo-x86_64.img
> -rw-r--r--  2 root root  8196820 Jan  9 22:15 
> initramfs-genkernel-x86_64-5.4.2-gentoo
> -rw-r--r--  2 root root  6804640 Jan  9 21:48 kernel
> -rw-r--r--  2 root root  6804640 Jan  9 21:48 
> kernel-genkernel-x86_64-5.4.2-gentoo
> drwx--  2 root root    12288 Apr 29  2019 lost+found
> -rw-r--r--  1 root root  6759584 Dec  6 20:22 vmlinuz-5.3.5-gentoo-x86_64
> -rw-r--r--  1 root root  6829216 Jan 11 19:49 vmlinuz-5.4.10-gentoo-x86_64
> 
> 
> As you can see they are missing from du output:
> 
> 19:56:48 [0] ~ >sudo du -hs /boot/System.map 
> /boot/System.map-5.3.5-gentoo-x86_64 
> /boot/System.map-genkernel-x86_64-5.4.2-gentoo /boot/efi /boot/grub 
> /boot/initramfs /boot/initramfs-5.3.5-gentoo-x86_64.img 
> /boot/initramfs-genkernel-x86_64-5.4.2-gentoo /boot/kernel 
> /boot/kernel-genkernel-x86_64-5.4.2-gentoo /boot/lost+found 
> /boot/vmlinuz-5.3.5-gentoo-x86_64
> 
> 3.3M    /boot/System.map
> 3.4M    /boot/System.map-5.3.5-gentoo-x86_64
> 1.0K    /boot/efi
> 9.7M    /boot/grub
> 7.9M    /boot/initramfs
> 16M    /boot/initramfs-5.3.5-gentoo-x86_64.img
> 6.5M    /boot/kernel
> 12K    /boot/lost+found
> 6.5M    /boot/vmlinuz-5.3.5-gentoo-x86_64
> 
> 
> When I remove the hard link from the arguments the corresponding file 
> appears in the output:
> 
> 19:56:51 [0] ~ >sudo du -hs /boot/System.map 
> /boot/System.map-5.3.5-gentoo-x86_64 
> /boot/System.map-genkernel-x86_64-5.4.2-gentoo /boot/efi /boot/grub 
> /boot/initramfs /boot/initramfs-5.3.5-gentoo-x86_64.img 
> /boot/initramfs-genkernel-x86_64-5.4.2-gentoo 
> /boot/kernel-genkernel-x86_64-5.4.2-gentoo /boot/lost+found 
> /boot/vmlinuz-5.3.5-gentoo-x86_64
> 
> 3.3M    /boot/System.map
> 3.4M    /boot/System.map-5.3.5-gentoo-x86_64
> 1.0K    /boot/efi
> 9.7M    /boot/grub
> 7.9M    /boot/initramfs
> 16M    /boot/initramfs-5.3.5-gentoo-x86_64.img
> 6.5M    /boot/kernel-genkernel-x86_64-5.4.2-gentoo
> 12K    /boot/lost+found
> 6.5M    /boot/vmlinuz-5.3.5-gentoo-x86_64
> 19:57:28 [0] ~ >
> 
> 
> Cheers,
> Alex.

du(1) should count the actual disc usage, and hard links do not
add more to that, so that was actually a bug fix back in coreutils-8.6:

  https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=efe53cc72b59

Discussion starts here:
  https://bugs.gnu.org/6557
  https://lists.gnu.org/r/bug-coreutils/2010-07/msg00015.html

This is intended behavior, and also documented in the Texinfo manual:

  https://www.gnu.org/software/coreutils/du

  If two or more hard links point to the same file, only one of the
  hard links is counted. The file argument order affects which links
  are counted, and changing the argument order may change the numbers
  and entries that du outputs.

I suggest to use the following option to make du(1) also count hard
links if needed:

  ‘-l’
  ‘--count-links’
Count the size of all files, even if they have appeared already (as a hard 
link).

As such, I'm hereby marking this as "not-a-bug", and close the issue in
out bug tracker.  However, the discussion about this can continue here,
of course.

Have a nice day,
Berny

bug#38908: Bug on comm or sort

[Bernhard Voelker]

tag 38908 notabug
close 38908
stop

Sent off-list:

On 2020-01-04 12:28, Saint Michael wrote:
> I agree, there is no bug. The issue could not be reproduced in another box. 
> My box had the issue.

Thanks for the confirmation.
I'm therefore closing this issue as not-a-bug in our bug tracker.

Have a nice day,
Berny

bug#38908: Bug on comm or sort

[Bernhard Voelker]

On 2020-01-04 01:28, Saint Michael wrote:
> I am trying to use the comm utility to compare two list of IP addresses,
> sorted with regular sort (not -n), and the result is erroneous. I could not
> find the answer in Google.
> 
> list1=
> 208.78.161.18
> 208.78.161.19
> 208.78.161.20
> 208.78.161.206
> 208.78.161.207
> 208.78.161.21
> 208.78.161.22
> 208.78.161.224
> 208.78.161.226
> 208.78.161.227
> 
> list2
> 208.78.161.17
> 208.78.161.18
> 208.78.161.19
> 208.78.161.20
> 208.78.161.206
> 208.78.161.207
> 208.78.161.21
> 208.78.161.22
> 208.78.161.224
> 208.78.161.226
> This command should work
>  comm -12 --check-order <(sort list1.txt) <(sort  list2.txt)
> my environment
> export LC_ALL=C
> export LANG=en_US.UTF-8
> export LC_CTYPE="en_US.UTF-8"
> export LC_COLLATE=C
> 
> why these lists are no being compared correctly?

Unfortunately, you did not mention the actual output of the
above command (and what exactly you think is wrong with it),
nor did you mention an error message.

Here, it gives (without error):

  $ comm -12 --check-order <(sort list1.txt) <(sort  list2.txt)
  208.78.161.18
  208.78.161.19
  208.78.161.20
  208.78.161.206
  208.78.161.207
  208.78.161.21
  208.78.161.22
  208.78.161.224
  208.78.161.226

which looks good, and BTW is identical with the output of
  $ sort list1.txt list2.txt | uniq -d

Have a nice day,
Berny

bug#38664: tail: unrecognized file system type 0x53464846 for ‘file’. please report this to bug-coreutils@gnu.org. reverting to polling

[Bernhard Voelker]

tag 38664 notabug
close 38664
stop

Hello,

On 2019-12-18 22:07, Thanassis Adamis wrote:
> Hi,
> This was encountered in Windows subsystem for linux.
> sample file is attached.
> 
> thanos@win10-ubuntu:~/down
> $ tail -f payments-schedule.txt
> 27/12/2019  EYDAP
> 30/12/2019  DEH
> tail: unrecognized file system type 0x53464846 for ‘payments-schedule.txt’.
> please report this to bug-coreutils@gnu.org. reverting to polling

Thanks for reporting.
Support for the 'wslfs' file system has been added in version 8.26
(and we're at 8.31 now).

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

Have a nice day,
Berny

bug#38621: gdu showing different sizes

[Bernhard Voelker]

On 2019-12-16 20:43, TJ Luoma wrote:
> AHA! Ok, now I understand a little better. I have seen the difference
> between "size" and "size on disk" and did not realize that applied
> here.

Thanks for confirming.

> I'm still not 100% clear on _why_ two "identical" files would have
> different results for "size on disk" (it _seems_ like those should be
> identical) but I suspect that the answer is probably of a technical
> nature that would be "over my head" so to speak, and truthfully, all I
> really need to know is "sometimes that happens" rather than
> understanding the technical details of why.

Actually the difference is a matter of choice, i.e., how the user wants to
save the file (obviously, most programs come with a certain default preference).

Suppose one writes a file with an "A" at the beginning, then e.g. 1.000.000 NUL
characters, and then a "B".

Then the storing algorithm may decide to either explicitly write all NULs
separately (here displayed as '.') to disk; e.g. 'cp --sparse=never' would do 
so:

  - write "A",
  - write 1.000.000 times a NUL,
  - write "B".

or to try to save some disk space by writing it as a "sparse" file;
e.g. 'cp --sparse=always' would (try to) do so:

  - write an "A",
  - then tell the filesystem that there are 1.000.000 NULs
(which takes just a few bytes physically),
  - write a "B"

The latter method needs support from both the tool and the file system
where the file is stored.

Or with your words: "sometimes that happens". ;-)

> I appreciate you taking the time to educate me further about this.

No worries.  If there's one user who got confused, then there is
the chance that also others might fall into the same issue.
Therefore, if you think we could improve something, e.g. a clarifying
word in the documentation, then this would help us all.

Thanks & have a nice day,
Berny

bug#38621: gdu showing different sizes

[Bernhard Voelker]

On 2019-12-16 07:25, TJ Luoma wrote:
> I sort of followed most of the technical part of that but I still don’t
> understand why it’s not a bug to show different information about two
> identical files.
> 
> Which may indicate that I didn’t understand the technical part very well.
> 
> As an end user, it’s hard to understand how that inconsistency isn’t both
> undesirable and a bug.
> 
> I could maybe see if they were two files with the same byte-count but
> different composition that made the calculations off by 1, but this is an
> identical file and it’s showing up with two different sizes, in a tool
> meant to report sizes.
> 
> That just seems “obviously” wrong even if it’s somehow technically
> explainable.

Thanks for following up on this for further clarifications.

I think the problem is the word "size":
while 'ls' and 'du --apparent-size' show the length of the content of
a file, 'du' (without --apparent-size') reports the space the file
needs on disk.

  $ du --help | sed 3q
  Usage: du [OPTION]... [FILE]...
or:  du [OPTION]... --files0-from=F
  Summarize disk usage of the set of FILEs, recursively for directories.
^^

One reason for those sizes to differ are "holes".  As an extreme case,
one can create a 4 Terabyte file (just NULs) on a filesystem which is
much smaller than that:

  # Filesystem size.
  $ df -h --out=size,target .
   Size Mounted on
   591G /mnt

  # Create a NUL-only file of size 4 Terabyte.
  $ truncate -s4T f2

  # 'ls' shows the 4T of file size.
  $ ls -logh f2
  -rw-r--r-- 1 4.0T Dec 16 08:36 f2

  # 'du' shows that the file does not even require any disk usage.
  $ du -h f2
  0 f2

  # ... but with '--apparent-size' reports the real (content) size.
  $ du -h --apparent-size f2
  4.0T  f2

  # Any program will see the 4T content transparently.
  $ wc -c < f2
  4398046511104

In your case, the file was a mixture of regular data and holes,
and 'cp' (without --sparse=always) tried to automatically determine
if the target file should have holes or not (see 'man cp').
Therefore, your 2 files had a different disk usage, but the net length
of the content is identical, of course.

Have a nice day,
Berny

bug#38621: gdu showing different sizes

[Bernhard Voelker]

tag 38621 notabug
close 38621
stop

On 2019-12-15 06:15, TJ Luoma wrote:
> I ended up with two version of the same file
> 'StreamDeck-4.4.2.12189.pkg' and 'Stream_Deck_4.4.2.12189.pkg' and
> wanted to check to see if they were the same file.
> 
> I checked the size with `gdu` like so:
> 
> % /usr/local/bin/gdu --si -s *pkg
> 101M StreamDeck-4.4.2.12189.pkg
> 102M Stream_Deck_4.4.2.12189.pkg
> 
> Which led me to think they were different files / sizes. But when I
> used `ls -l` I was surprised to see this:
> 
> % command ls -l *pkg
> -rw-r--r--  1 tjluoma  staff  5047 Dec 15 00:00 StreamDeck-4.4.2.12189.pkg
> -rw-r--r--@ 1 tjluoma  staff  5047 Dec 15 00:02 
> Stream_Deck_4.4.2.12189.pkg
> 
> So they _are_ the same size. Are they the same file? I used `md5` to check
> 
> % command md5 -r *pkg
> 98ac563a36386ca3aa87f62893302b4f StreamDeck-4.4.2.12189.pkg
> 98ac563a36386ca3aa87f62893302b4f Stream_Deck_4.4.2.12189.pkg
> 
> OK, so these are exactly the same file. So… why did `gdu` tell me they
> are different sizes?
> 
> %  gdu --version
> du (GNU coreutils) 8.31
> Copyright (C) 2019 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> .
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by Torbjorn Granlund, David MacKenzie, Paul Eggert,
> and Jim Meyering.
> 
> I'm using Mac OS X 10.14.6 (18G2022) with `coreutils` installed via `brew`.
> 
> Any help would be appreciated.

This is a "sparse" file, i.e., a file with longer sequences of Zeroes
somewhere in between which can be stored more efficient on the disk.
Any application reading the data will get the correct number of Zeroes,
while some disk space is saved.

E.g. the following creates a 300M file, with the first 100M and the last 100M
with random data, and the 100M between is a "hole":

  # Write the 1st 100M (as usual).
  $ dd bs=1M count=100 if=/dev/urandom of=f
  100+ 0 records in
  100+0 records out
  104857600 bytes (105 MB, 100 MiB) copied, 0.466356 s, 225 MB/s

  # Write another 100M, but starting at a position of 200M,
  # thus leaving Zeroes in between.
  $ dd bs=1M seek=200 count=100 if=/dev/urandom of=f
  100+0 records in
  100+0 records out
  104857600 bytes (105 MB, 100 MiB) copied, 0.462072 s, 227 MB/s

  $ ls -logh f
  -rw-r--r-- 1 300M Dec 15 18:17 f

  $ du -h f  # shows the space occupied on disk.
  200M  f

  $ du --apparent-size -h f  # shows the size applications would read.
  300M  f

See the documentation of 'cp' and 'du':
https://www.gnu.org/software/coreutils/cp  (the --sparse option)
https://www.gnu.org/software/coreutils/du  (the --apparent-size option)

As this is not a bug in du(1), I'm marking this as such, and close the ticket
in our bug tracker.  The discussion can continue, of course.

Have a nice day,
Berny

bug#38285: Error Vyos

[Bernhard Voelker]

tag 38285 notabug
close 38285
stop

Hello,

On 2019-11-20 01:27, aurele janniere wrote:
> Hello sorry for my English I have a problem with Vyos when I type monitor
> dhcp example I have this error "tail: unrecognized file system type
> 0x794c7630 for ‘/var/log/messages’. please report this to
> bug-coreutils@gnu.org. reverting to polling
> " Thank you.

overlayfs - commonly used with Docker containers - has been added
in version 8.25. Consider upgrading Coreutils if possible.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

Have a nice day,
Berny

bug#38221: tail: unrecognized file system type 0x794c7630

[Bernhard Voelker]

tag 38221 notabug
close 38221
stop

Hello,

On 2019-11-15 09:24, enrojhu...@mail.tainaron.de wrote:
> Hello,
> 
> 'tail' asked me to to report this to you:
> 
> tail: unrecognized file system type 0x794c7630 for '***'. please report
> this to bug-coreutils@gnu.org. reverting to polling
> 
> I'm using an overlay file system here.
> If you need more information, please ask.
> 
> Best,
> 
> Tobias

overlayfs - commonly used with Docker containers - has been added
in version 8.25. Consider upgrading Coreutils if possible.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

Have a nice day,
Berny