bug#33287: [PATCH] sync: add missing brackets in sync_arg()

[Paul Eggert]

On 11/6/18 3:33 PM, Bernhard Voelker wrote:

Should we add a NEWS entry and a test - see attached?


Thanks, good point, and I installed that.

bug#33287: [PATCH] sync: add missing brackets in sync_arg()

[Bernhard Voelker]

On 11/6/18 7:35 PM, Paul Eggert wrote:
> Thanks, I installed that and am closing the bug report.

That was a real bug, i.e., not only a resource leak, wasn't it?

If the calling user has -r+w permissions on the file, then sync previously
exited with 1 without actually syncing:

  $ install -m 0200 /dev/null /tmp/file

  $ ls -log /tmp/file
  --w--- 1 0 Nov  7 00:06 /tmp/file

  $ strace -v /usr/bin/sync /tmp/file 2>&1 | tail -n6
  openat(AT_FDCWD, "/tmp/file", O_RDONLY|O_NONBLOCK) = -1 EACCES (Permission 
denied)
  openat(AT_FDCWD, "/tmp/file", O_WRONLY|O_NONBLOCK) = 3
  close(1)= 0
  close(2)= 0
  exit_group(1)   = ?
  +++ exited with 1 +++

With the patch, fsync is called, and sync terminated with success:

  $ strace -v src/sync /tmp/file 2>&1 | tail
  openat(AT_FDCWD, "/tmp/file", O_RDONLY|O_NONBLOCK) = -1 EACCES (Permission 
denied)
  openat(AT_FDCWD, "/tmp/file", O_WRONLY|O_NONBLOCK) = 3
  fcntl(3, F_GETFL)   = 0x8801 (flags 
O_WRONLY|O_NONBLOCK|O_LARGEFILE)
  fcntl(3, F_SETFL, O_WRONLY|O_LARGEFILE) = 0
  fsync(3)= 0
  close(3)= 0
  close(1)= 0
  close(2)= 0
  exit_group(0)   = ?
  +++ exited with 0 +++

Should we add a NEWS entry and a test - see attached?

Thanks & have a nice day,
Berny
From 90679f499b71f2432a7faa439bc7a9155e7bee9c Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Wed, 7 Nov 2018 00:26:01 +0100
Subject: [PATCH] sync: add NEWS and test for the fix in the previous commit

* NEWS (Bug fixes): Mention the fix in commit 94d364f157f0.
While at it, remove duplicate "Changes in behavior" heading.
* tests/misc/sync.sh: Add a test with a write-only file for the fix.
---
 NEWS   | 5 +++--
 tests/misc/sync.sh | 7 ++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/NEWS b/NEWS
index 088810fe8..8c1283549 100644
--- a/NEWS
+++ b/NEWS
@@ -11,6 +11,9 @@ GNU coreutils NEWS-*- outline -*-
   df no longer corrupts displayed multibyte characters on macOS.
   [bug introduced with coreutils-8.18]
 
+  sync no longer fails for write-only file arguments.
+  [bug introduced with argument support to sync in coreutils-8.24]
+
 ** Changes in behavior
 
   echo now always processes backslash escapes when the POSIXLY_CORRECT
@@ -22,8 +25,6 @@ GNU coreutils NEWS-*- outline -*-
   approach is still used in situations where hard links to directories
   are allowed (e.g., NetBSD when superuser).
 
-** Changes in behavior
-
   'test -a FILE' is not supported anymore.  Long ago, there were concerns about
   the high probability of humans confusing the -a primary with the -a binary
   operator, so POSIX changed this to 'test -e FILE'.  Scripts using it were
diff --git a/tests/misc/sync.sh b/tests/misc/sync.sh
index f60d28c5a..3bb6e179e 100755
--- a/tests/misc/sync.sh
+++ b/tests/misc/sync.sh
@@ -19,7 +19,7 @@
 . "${srcdir=.}/tests/init.sh"; path_prepend_ ./src
 print_ver_ sync
 
-touch file
+touch file || framework_failure_
 
 # fdatasync+syncfs is nonsensical
 returns_ 1 sync --data --file-system || fail=1
@@ -30,6 +30,11 @@ returns_ 1 sync -d || fail=1
 # Test syncing of file (fsync) (little side effects)
 sync file || fail=1
 
+# Test syncing of write-only file - which failed since adding argument
+# support to sync in coreutils-8.24.
+chmod 0200 file || framework_failure_
+sync file || fail=1
+
 # Ensure multiple args are processed and diagnosed
 returns_ 1 sync file nofile || fail=1
 
-- 
2.19.1

bug#33281: head does not consume input after '-c' is satisfied

[Paul Eggert]

On 11/5/18 1:17 PM, Philip Rowlands wrote:

To achieve consistency in the other direction, head could ignore the 
optimization to reduce the number of bytes read, and always read 8192 bytes, 
knowing that some would be discarded.


Let's not do that. It's less efficient and less useful than what GNU 
'head -c4' is doing now.



For widely differing values, the only way to produce the same residual output 
would be to consume all input data.


Eeuuww. Let's *especially* not do that.

bug#18168: Bug in "sort -V" ?

[Assaf Gordon]

tags 18168 notabug
close 18168
stop

(triaging old bugs)

Hello,

It seems your message was lost and not replied to in 4 years.
Sorry about that.

On 2014-08-01 3:38 a.m., Schleusener, Jens wrote:
I am not sure if it's a bug or not but for my application cases the 
"sort" command with use of the very helpful option "-V" (natural sort of 
(version) numbers within text) not always delivers the by me expected 
output.


Note that "-V/--version" is specifically sorting by Debian's *version*
sorting rules. It might seem like it's the same as "natural sort", but
it is not.

The exact rules are here:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#version
https://readme.phys.ethz.ch/documentation/debian_version_numbers/



Example input file (with four test cases):

1.0.5_src.tar.gz
1.0_src.tar.gz
2.0.5src.tar.gz
2.0src.tar.gz
3.0.5/
3.0/
4.0.5beta/
4.0beta/

Sorted ("sort -V") output file (with errors?):

1.0.5_src.tar.gz
1.0_src.tar.gz
2.0src.tar.gz
2.0.5src.tar.gz
3.0.5/
3.0/
4.0beta/
4.0.5beta/

By me expected output file:

1.0_src.tar.gz
1.0.5_src.tar.gz
2.0src.tar.gz
2.0.5src.tar.gz
3.0/
3.0.5/
4.0beta/
4.0.5beta/


The disagreement is about "1.0_src.tar.gz" vs "1.0.5_src.tar.gz"
and "3.0/" vs "3.0.5/" .

Note that these characters are not strictly valid characters in debian
version strings.

Let's try to compare them using Debian's own tools:

First, define a tiny shell function to help compare strings:

compver() {
   dpkg --compare-versions "$1" lt "$2" \
&& printf "%s\n" "$1" "$2" \
|| printf "%s\n" "$2" "$1"
}

Then, compare the values:

  $ compver 1.0.5_src.tar.gz 1.0_src.tar.gz
  dpkg: warning: version '1.0.5_src.tar.gz' has bad syntax: invalid 
character in version number
  dpkg: warning: version '1.0_src.tar.gz' has bad syntax: invalid 
character in version number

  1.0.5_src.tar.gz
  1.0_src.tar.gz

  $ compver 3.0/ 3.0.5/
  dpkg: warning: version '3.0/' has bad syntax: invalid character in 
version number
  dpkg: warning: version '3.0.5/' has bad syntax: invalid character in 
version number

  3.0.5/
  3.0/

So sort's order agrees with Debian's ordering rules.
It might not be what a "natural sort" algorithm would do, but version-sort
is not exactly natural-sort.

Another detailed example of a version-sort is here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22275 




As such, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#33287: [PATCH] sync: add missing brackets in sync_arg()

[Paul Eggert]

Thanks, I installed that and am closing the bug report.

bug#15023: Coreutils on IRIX

[Paul Eggert]

What was left of SGI stopped supporting IRIX in December 2013, so we can 
close IRIX-related bugs without much fuss.

bug#23645: GNU coreutils 8.25 make check report

[Assaf Gordon]

close 23645
stop

On 2018-10-28 12:00 a.m., Assaf Gordon wrote:

(triaging old bugs)

Hello,

On 2016-05-29 12:22 a.m., Donald A. MacDonald wrote:

Just build coreutils on a MacBook Pro running OS X 10.11.5 (El Capitan)



Are you still experiencing these failures (perhaps with more recent
coreutils version, or more recent Mac OS X version) ?




For now I'm closing this bug.
If this issue still occurs, we'll reopen it.
Discussion can continue by replying to this thread.

-assaf

bug#15023: Coreutils on IRIX

[Assaf Gordon]

tags 15023 moreinfo
close 15023
stop

(triaging old bugs)

On 2013-08-09 2:26 p.m., Paul Eggert wrote:

One other thing.  Under what conditions do
 include ?

[...]

and so I'd like to know which symbols protect the
inclusion of  (here it includes _SYS_TIME_H
and the others).


With no replies or further follow-ups in 5 years,
I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#12741: any cross-compile fails due to new make-prime-list

[Assaf Gordon]

tags 12741 fixed
close 12741
stop

(triaging old bugs)

On 2012-10-26 11:27 a.m., Jim Meyering wrote:

That would be fine with me.
We were precomputing the "wheel.h" table of primes before, too.

If we go the route of distributing the generated file,
then we might as well resort to using Perl and say, -Mbigint,
to do generate all variants.


Starting with version 8.21, "prime.h" is pre-built and distributed.

Committed here:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=f16e251dae43117c2cd19359c26ce7b5e05165b6

As such, closing this bug.

-assaf

bug#12453: failed test suite on 64-bit debian squeeze

[Assaf Gordon]

tags 12453 moreinfo
close 12453
stop


On 2012-09-16 2:38 p.m., Jim Meyering wrote:

Thank you for reporting that.
At first glance, that failing assertion seems due to a bug in your
system's version of valgrind.  I don't immediately see a clean way
to work around it.  Sure, the dirty way would be to search for this
line:


With no further comments in 6 years, I'm closing this bug.

-assaf

bug#33289: tail -f error within docker container

[Assaf Gordon]

tags 33289 notabug
close 33289
stop

Hello,

On 2018-11-06 2:05 a.m., Jörgen Christiansson wrote:
I get this message when doing tail -f on a regular file within a docker 
container.


tail: unrecognized file system type 0x794c7630 for 
‘/var/opt/system/log/snmpexport.trc0’. please report this to 
bug-coreutils@gnu.org. reverting to polling




Thanks for the report.
This filesystem has been supported since version 8.25.
You are likely using an older version.

For details, see: https://www.gnu.org/software/coreutils/filesystems.html

regards,
 - assaf

bug#33288: Bug report - tail: unrecognized file system type

[Assaf Gordon]

tags 33288 notabug
close 33288
stop

Hello,

On 2018-11-06 6:26 a.m., Adam Solymos wrote:

I have encountered an issue in tail command when running it in a Debian based 
Linux distro (Linux f596ea7f8fe0 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:55:56 
UTC 2018 x86_64 GNU/Linux) in a Docker container on a Windows 10 host OS.

Error message:
tail: unrecognized file system type 0xfe534d42 for 'errors.log'. please report 
this to bug-coreutils@gnu.org. reverting to polling


Thanks for the report.
This filesystem has been supported since version 8.26.
You are likely using an older version.

For details, see: https://www.gnu.org/software/coreutils/filesystems.html

regards,
 - assaf

bug#33288: Bug report - tail: unrecognized file system type

[Adam Solymos]

Hi,

I have encountered an issue in tail command when running it in a Debian based 
Linux distro (Linux f596ea7f8fe0 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:55:56 
UTC 2018 x86_64 GNU/Linux) in a Docker container on a Windows 10 host OS.

Error message:
tail: unrecognized file system type 0xfe534d42 for 'errors.log'. please report 
this to bug-coreutils@gnu.org. reverting to polling

Kind regards,

Adam Solymos
Software Developer

ESPC
Tel: 0131 624 8000
90a George Street, Edinburgh, EH2 3DF

Website | Facebook | 
Twitter | 
Instagram | 
LinkedIn




[http://assets.espc.com/sig/SHA_Finalist.png] 
[http://assets.espc.com/sig/SLA.png]
Private and Confidential: This e-mail transmission is strictly confidential and 
intended solely for the addressee. It may contain privileged and confidential 
information and if you are not the intended recipient, you must not copy, 
disclose, distribute or take any action in reliance on it. If you have received 
this e-mail in error, please delete it and notify our E-mail Systems 
Administrator on +44 (0) 131 624 8000. ESPC (UK) Ltd does not accept any 
liability for any harm that may be caused to the recipient's system or data by 
this message or any attachment.
ESPC (UK) Ltd is a company registered under the Companies Acts in Scotland 
(Registered Number SC203585), and having its registered office at 90A George 
Street, Edinburgh, Midlothian EH2 3DF.
ESPC (UK) Ltd is an Appointed Representative of Lyncombe Consultants Ltd which 
is authorised and regulated by the Financial Conduct Authority.

bug#33289: tail -f error within docker container

[Jörgen Christiansson]

Hi!

I get this message when doing tail -f on a regular file within a docker 
container.


tail: unrecognized file system type 0x794c7630 for 
‘/var/opt/system/log/snmpexport.trc0’. please report this to 
bug-coreutils@gnu.org. reverting to polling


>docker version
Client version: 1.4.1-dev
Client API version: 1.17
Go version (client): go1.3.1
Git commit (client): d26b358/1.4.1
OS/Arch (client): linux/amd64
FATA[] Get http:///var/run/docker.sock/v1.17/version: dial unix 
/var/run/docker.sock: no such file or directory. Are you trying to 
connect to a TLS-enabled daemon without TLS?


--
   Jörgen Christiansson
   Netsoft Lund Development AB
   Bredgatan 17  222 21 Lund
   Phone: 046-190492   Mobile: 0702-179385

bug#33287: [PATCH] sync: add missing brackets in sync_arg()

[Kamil Dudka]

Detected by Coverity Analysis:

Error: RESOURCE_LEAK (CWE-772):
coreutils-8.30/src/sync.c:112: open_fn: Returning handle opened by "open".
coreutils-8.30/src/sync.c:112: var_assign: Assigning: "fd" = handle returned 
from "open(file, 2049)".
coreutils-8.30/src/sync.c:115: leaked_handle: Handle variable "fd" going out of 
scope leaks the handle.
113| if (fd < 0)
114|   error (0, rd_errno, _("error opening %s"), quoteaf (file));
115|->   return false;
116|   }
117|
---
 src/sync.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/sync.c b/src/sync.c
index bd3671a19..607fa8f7f 100644
--- a/src/sync.c
+++ b/src/sync.c
@@ -111,8 +111,10 @@ sync_arg (enum sync_mode mode, char const *file)
   if (open_flags != (O_WRONLY | O_NONBLOCK))
 fd = open (file, O_WRONLY | O_NONBLOCK);
   if (fd < 0)
-error (0, rd_errno, _("error opening %s"), quoteaf (file));
-  return false;
+{
+  error (0, rd_errno, _("error opening %s"), quoteaf (file));
+  return false;
+}
 }
 
   /* We used O_NONBLOCK above to not hang with fifos,
-- 
2.17.2