bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-16 Thread Paul Eggert 

On 11/16/21 08:40, Sudhip Nashi via GNU coreutils Bug Reports wrote:


It looks like this patch fixes the problem, and a quick checksum verifies this.


Thanks for checking. Closing the Coreutils bug report.

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-16 Thread Sudhip Nashi via GNU coreutils Bug Reports 


> So, not only does macOS lseek disagree with all other implementations, it 
> even disagrees with the Darwin documentation.
Oh wow, that’s convoluted.

> To work around this macOS problem I installed the attached further patch into 
> Gnulib and propagated it into coreutils. Please try the latest coreutils 
> version on Savannah, or you can simply run configure+make from the tarball 
> that is temporarily at:
> 
> https://web.cs.ucla.edu/~eggert/coreutils-9.0.28-6d0f0.tar.gz
> <0001-lseek-port-around-macOS-SEEK_HOLE-glitch.patch>
It looks like this patch fixes the problem, and a quick checksum verifies this.

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Paul Eggert 

On 11/15/21 19:14, Sudhip Nashi wrote:

lseek(0x3, 0x0, 0x3) = -1 Err#6


Oh my, it appears lseek (fd, 0, SEEK_HOLE) is failing with errno == 
ENXIO when the file has no holes, even though the Darwin man page 
clearly states that lseek should return the file size in that case (see 
). 
So, not only does macOS lseek disagree with all other implementations, 
it even disagrees with the Darwin documentation.


To work around this macOS problem I installed the attached further patch 
into Gnulib and propagated it into coreutils. Please try the latest 
coreutils version on Savannah, or you can simply run configure+make from 
the tarball that is temporarily at:


https://web.cs.ucla.edu/~eggert/coreutils-9.0.28-6d0f0.tar.gzFrom 1a268176fbb184e393c98575e61fe692264c7d91 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 15 Nov 2021 22:17:44 -0800
Subject: [PATCH] lseek: port around macOS SEEK_HOLE glitch

Problem reported by Sudhip Nashi (Bug#51857#47).
* lib/lseek.c (rpl_lseek): Work around macOS lseek+SEEK_HOLE
returning -1 with ENXIO if there are no holes before EOF,
contrary to the macOS documentation.
---
 ChangeLog   | 6 ++
 lib/lseek.c | 6 --
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 71a226570..efc3a3887 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2021-11-15  Paul Eggert  
 
+	lseek: port around macOS SEEK_HOLE glitch
+	Problem reported by Sudhip Nashi (Bug#51857#47).
+	* lib/lseek.c (rpl_lseek): Work around macOS lseek+SEEK_HOLE
+	returning -1 with ENXIO if there are no holes before EOF,
+	contrary to the macOS documentation.
+
 	lseek: port around macOS SEEK_DATA glitch
 	Problem reported by Sudhip Nashi (Bug#51857).
 	* doc/posix-functions/lseek.texi (lseek): Mention macOS SEEK_DATA
diff --git a/lib/lseek.c b/lib/lseek.c
index 7dcd6c9da..e9a96ad20 100644
--- a/lib/lseek.c
+++ b/lib/lseek.c
@@ -61,10 +61,12 @@ rpl_lseek (int fd, off_t offset, int whence)
  data followed by a possibly-empty hole.  To work around this
  portability glitch, check whether OFFSET is within data by
  using lseek+SEEK_HOLE, and if so return to OFFSET by using
- lseek+SEEK_SET.  */
+ lseek+SEEK_SET.  Also, contrary to the macOS documentation,
+ lseek+SEEK_HOLE can fail with ENXIO if there are no holes on
+ or after OFFSET.  What a mess!  */
   off_t next_hole = lseek (fd, offset, SEEK_HOLE);
   if (next_hole < 0)
-return next_hole;
+return errno == ENXIO ? offset : next_hole;
   if (next_hole != offset)
 whence = SEEK_SET;
 }
-- 
2.32.0

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Paul Eggert 

On 11/15/21 19:14, Sudhip Nashi wrote:

lseek(0x3, 0x0, 0x3) = -1 Err#6


Oh my, it appears lseek (fd, 0, SEEK_HOLE) is failing with errno == 
ENXIO when the file has no holes, even though the Darwin man page 
clearly states that lseek should return the file size in that case (see 
). 
So, not only does macOS lseek disagree with all other implementations, 
it even disagrees with the Darwin documentation.


To work around this macOS problem I installed the attached further patch 
into Gnulib and propagated it into coreutils. Please try the latest 
coreutils version on Savannah, or you can simply run configure+make from 
the tarball that is temporarily at:


https://web.cs.ucla.edu/~eggert/coreutils-9.0.28-6d0f0.tar.gzFrom 1a268176fbb184e393c98575e61fe692264c7d91 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 15 Nov 2021 22:17:44 -0800
Subject: [PATCH] lseek: port around macOS SEEK_HOLE glitch

Problem reported by Sudhip Nashi (Bug#51857#47).
* lib/lseek.c (rpl_lseek): Work around macOS lseek+SEEK_HOLE
returning -1 with ENXIO if there are no holes before EOF,
contrary to the macOS documentation.
---
 ChangeLog   | 6 ++
 lib/lseek.c | 6 --
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 71a226570..efc3a3887 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2021-11-15  Paul Eggert  
 
+	lseek: port around macOS SEEK_HOLE glitch
+	Problem reported by Sudhip Nashi (Bug#51857#47).
+	* lib/lseek.c (rpl_lseek): Work around macOS lseek+SEEK_HOLE
+	returning -1 with ENXIO if there are no holes before EOF,
+	contrary to the macOS documentation.
+
 	lseek: port around macOS SEEK_DATA glitch
 	Problem reported by Sudhip Nashi (Bug#51857).
 	* doc/posix-functions/lseek.texi (lseek): Mention macOS SEEK_DATA
diff --git a/lib/lseek.c b/lib/lseek.c
index 7dcd6c9da..e9a96ad20 100644
--- a/lib/lseek.c
+++ b/lib/lseek.c
@@ -61,10 +61,12 @@ rpl_lseek (int fd, off_t offset, int whence)
  data followed by a possibly-empty hole.  To work around this
  portability glitch, check whether OFFSET is within data by
  using lseek+SEEK_HOLE, and if so return to OFFSET by using
- lseek+SEEK_SET.  */
+ lseek+SEEK_SET.  Also, contrary to the macOS documentation,
+ lseek+SEEK_HOLE can fail with ENXIO if there are no holes on
+ or after OFFSET.  What a mess!  */
   off_t next_hole = lseek (fd, offset, SEEK_HOLE);
   if (next_hole < 0)
-return next_hole;
+return errno == ENXIO ? offset : next_hole;
   if (next_hole != offset)
 whence = SEEK_SET;
 }
-- 
2.32.0

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Sudhip Nashi via GNU coreutils Bug Reports 
Sure, here’s the dtruss output:

SYSCALL(args)= return
access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0) = -1 Err#2
bsdthread_register(0x1AEC802C8, 0x1AEC802BC, 0x4000) = 1073742303 0
shm_open(0x1AEB48F55, 0x0, 0xDD8000) = 3 0
fstat64(0x3, 0x16F0260D0, 0x0)   = 0 0
mmap(0x0, 0x4000, 0x1, 0x40001, 0x3, 0x0)= 0x100F18000 0
close(0x3)   = 0 0
ioctl(0x2, 0x4004667A, 0x16F02617C)  = -1 Err#25
ioctl(0x2, 0x40487413, 0x16F026180)  = -1 Err#25
mprotect(0x100F24000, 0x4000, 0x0)   = 0 0
mprotect(0x100F3, 0x4000, 0x0)   = 0 0
mprotect(0x100F34000, 0x4000, 0x0)   = 0 0
mprotect(0x100F4, 0x4000, 0x0)   = 0 0
mprotect(0x100F44000, 0x4000, 0x0)   = 0 0
mprotect(0x100F5, 0x4000, 0x0)   = 0 0
mprotect(0x100F1C000, 0x90, 0x1) = 0 0
mprotect(0x100F1C000, 0x90, 0x3) = 0 0
mprotect(0x100F1C000, 0x90, 0x1) = 0 0
mprotect(0x100F54000, 0x4000, 0x1)   = 0 0
mprotect(0x100F58000, 0x90, 0x1) = 0 0
mprotect(0x100F58000, 0x90, 0x3) = 0 0
mprotect(0x100F58000, 0x90, 0x1) = 0 0
mprotect(0x100F1C000, 0x90, 0x3) = 0 0
mprotect(0x100F1C000, 0x90, 0x1) = 0 0
mprotect(0x100F54000, 0x4000, 0x3)   = 0 0
mprotect(0x100F54000, 0x4000, 0x1)   = 0 0
objc_bp_assist_cfg_np(0x1AEB103C0, 0x80201048, 0x0)  = -1 
Err#5
issetugid(0x0, 0x0, 0x0) = 0 0
getentropy(0x16F025F98, 0x20, 0x0)   = 0 0
getentropy(0x16F025FE8, 0x40, 0x0)   = 0 0
getpid(0x0, 0x0, 0x0)= 45930 0
stat64("/AppleInternal\0", 0x16F0266E0, 0x0) = -1 Err#2
csops_audittoken(0xB36A, 0x7, 0x16F026210)   = 0 0
proc_info(0x2, 0xB36A, 0xD)  = 64 0
csops_audittoken(0xB36A, 0x7, 0x16F0262D0)   = 0 0
sysctlbyname(kern.osvariant_status, 0x15, 0x16F026748, 0x16F026740, 0x0)
 = 0 0
csops(0xB36A, 0x0, 0x16F02676C)  = 0 0
mprotect(0x100E1, 0x10, 0x1) = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_COLLATE\0", 0x0, 0x0)   
 = 3 0
fcntl_nocancel(0x3, 0x3, 0x0)= 0 0
getrlimit(0x1008, 0x16F027118, 0x0)  = 0 0
fstat64(0x3, 0x16F027090, 0x0)   = 0 0
read_nocancel(0x3, "1.1A\n\0", 0x1000)   = 2086 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_CTYPE\0", 0x0, 0x0) 
 = 3 0
fcntl_nocancel(0x3, 0x3, 0x0)= 0 0
fstat64(0x3, 0x16F0271C0, 0x0)   = 0 0
fstat64(0x3, 0x16F026FB0, 0x0)   = 0 0
lseek(0x3, 0x0, 0x1) = 0 0
lseek(0x3, 0x0, 0x0) = 0 0
read_nocancel(0x3, "RuneMagAUTF-8\0", 0x1000)= 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "@\004\211\0", 0xF5D0)= 62928 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_MONETARY\0", 0x0, 0x0)  
 = 3 0
fstat64(0x3, 0x16F0271E0, 0x0)   = 0 0
read_nocancel(0x3, "USD \n$\n.\n,\n3;3\n\n-\n2\n2\n1\n0\n1\n0\n1\n1\n(\0", 
0x22) = 34 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_NUMERIC\0", 0x0, 0x0)   
 = 3 0
fstat64(0x3, 0x16F0271E0, 0x0)   = 0 0
read_nocancel(0x3, ".\n,\n3;3\n@$\b\0", 0x8) = 8 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_TIME\0", 0x0, 0x0)  
 = 3 0
fstat64(0x3, 0x16F0271F0, 0x0)   = 0 0
read_nocancel(0x3, 
"Jan\nFeb\nMar\nApr\nMay\nJun\nJul\nAug\nSep\nOct\nNov\nDec\nJanuary\nFebruary\nMarch\nApril\nMay\nJune\nJuly\nAugust\nSeptember\nOctober\nNovember\nDecember\nSun\nMon\nTue\nWed\nThu\nFri\nSat\nSunday\nMonday\nTuesday\nWednesday\nThursday\nFriday\nSaturday\n%H:%M:%S\n%m/%d/%Y\n%a
 %b %e %X %Y\nAM\nP", 0x179)  = 377 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/LC_MESSAGES\0", 0x0, 
0x0)   = 3 0
fstat64(0x3, 0x16F0271F0, 0x0)   = 0 0
read_nocancel(0x3, "^[yYsS].*\n^[nN].*\n(\0", 0x12)  = 18 0
close_nocancel(0x3)  = 0 0
geteuid(0x0, 0x0, 0x0)   = 0 0
stat64("/tmp/filetest\0", 0x16F0276C0, 0x0)  = -1 Err#2
fstatat64(0xFFFE, 0x16F027BDD, 0x16F027390)  = 0 0
fstatat64(0xFFFE, 0x16F027C0B, 0x16F027300)  = -1 Err#2
open("/System/Library/dyld/dyld_shared_cache_arm64e\0", 0x0, 0x0)

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Paul Eggert 

On 11/15/21 16:02, Sudhip Nashi wrote:

It doesn’t seem like this patch works. I compiled from the tarball you 
provided, but the destination file is still filled with NULL chars.


Too bad. Can you do a dtruss or at least a ktrace/kdump for the failing 
program? I'd like to see what lseek is doing with SEEK_HOLE and 
SEEK_DATA. Thanks.

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Sudhip Nashi via GNU coreutils Bug Reports 
It doesn’t seem like this patch works. I compiled from the tarball you 
provided, but the destination file is still filled with NULL chars.
> On Nov 15, 2021, at 5:46 PM, Sudhip Nashi via GNU coreutils Bug Reports 
>  wrote:
> 
> Awesome, thanks for the quick response! I’ll give this a go and let you know 
> the results.
> 
>> On Nov 15, 2021, at 5:41 PM, Paul Eggert  wrote:
>> 
>> On 11/15/21 10:37, Sudhip Nashi wrote:
>>> Turns out lseek is broken (or at least works differently) on macOS as well 
>>> (https://lists.gnu.org/archive/html/bug-gnulib/2018-09/msg00054.html). 
>>> Funny coincidence! I’ll take a better look later this week if I can and try 
>>> to see what the exact problem is.
>> 
>> Thanks, I think I see the problem now.
>> 
>> Eventually macOS will likely get fixed to work around this lseek+SEEK_DATA 
>> incompatibility (as FreeBSD, Solaris, etc. all do things the Linux way and 
>> that's what I think will appear in the next POSIX), but in the meantime I 
>> attempted to work around the portability issue by installing the attached 
>> patch into Gnulib, and by syncing coreutils to the latest Gnulib.
>> 
>> I don't use macOS so have not tested this. Please give it a try, either by 
>> building from bleeding-edge coreutils on Savannah, or by building from the 
>> tarball temporarily here:
>> 
>> https://www.cs.ucla.edu/~eggert/coreutils-9.0.26-0f4d9.tar.gz
>> 
>> Thanks.<0001-lseek-port-around-macOS-SEEK_DATA-glitch.patch>
> 
> 
> 
>

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Sudhip Nashi via GNU coreutils Bug Reports 
Awesome, thanks for the quick response! I’ll give this a go and let you know 
the results.

> On Nov 15, 2021, at 5:41 PM, Paul Eggert  wrote:
> 
> On 11/15/21 10:37, Sudhip Nashi wrote:
>> Turns out lseek is broken (or at least works differently) on macOS as well 
>> (https://lists.gnu.org/archive/html/bug-gnulib/2018-09/msg00054.html). Funny 
>> coincidence! I’ll take a better look later this week if I can and try to see 
>> what the exact problem is.
> 
> Thanks, I think I see the problem now.
> 
> Eventually macOS will likely get fixed to work around this lseek+SEEK_DATA 
> incompatibility (as FreeBSD, Solaris, etc. all do things the Linux way and 
> that's what I think will appear in the next POSIX), but in the meantime I 
> attempted to work around the portability issue by installing the attached 
> patch into Gnulib, and by syncing coreutils to the latest Gnulib.
> 
> I don't use macOS so have not tested this. Please give it a try, either by 
> building from bleeding-edge coreutils on Savannah, or by building from the 
> tarball temporarily here:
> 
> https://www.cs.ucla.edu/~eggert/coreutils-9.0.26-0f4d9.tar.gz
> 
> Thanks.<0001-lseek-port-around-macOS-SEEK_DATA-glitch.patch>

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Paul Eggert 

On 11/15/21 10:37, Sudhip Nashi wrote:

Turns out lseek is broken (or at least works differently) on macOS as well 
(https://lists.gnu.org/archive/html/bug-gnulib/2018-09/msg00054.html). Funny 
coincidence! I’ll take a better look later this week if I can and try to see 
what the exact problem is.


Thanks, I think I see the problem now.

Eventually macOS will likely get fixed to work around this 
lseek+SEEK_DATA incompatibility (as FreeBSD, Solaris, etc. all do things 
the Linux way and that's what I think will appear in the next POSIX), 
but in the meantime I attempted to work around the portability issue by 
installing the attached patch into Gnulib, and by syncing coreutils to 
the latest Gnulib.


I don't use macOS so have not tested this. Please give it a try, either 
by building from bleeding-edge coreutils on Savannah, or by building 
from the tarball temporarily here:


https://www.cs.ucla.edu/~eggert/coreutils-9.0.26-0f4d9.tar.gz

Thanks.From 4db8db34112b86ddf8bac48f16b5acff732b5fa9 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 15 Nov 2021 15:08:25 -0800
Subject: [PATCH] lseek: port around macOS SEEK_DATA glitch

Problem reported by Sudhip Nashi (Bug#51857).
* doc/posix-functions/lseek.texi (lseek): Mention macOS SEEK_DATA
issue.
* lib/lseek.c (rpl_lseek): Work around macOS portability glitch.
* m4/lseek.m4 (gl_FUNC_LSEEK): Replace lseek on Darwin.
* modules/lseek (Depends-on): Depend on msvc-nothrow
and fstat only if needed.
---
 ChangeLog  | 11 +++
 doc/posix-functions/lseek.texi |  4 
 lib/lseek.c| 16 
 m4/lseek.m4| 10 --
 modules/lseek  |  4 ++--
 5 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f47071a72..71a226570 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2021-11-15  Paul Eggert  
+
+	lseek: port around macOS SEEK_DATA glitch
+	Problem reported by Sudhip Nashi (Bug#51857).
+	* doc/posix-functions/lseek.texi (lseek): Mention macOS SEEK_DATA
+	issue.
+	* lib/lseek.c (rpl_lseek): Work around macOS portability glitch.
+	* m4/lseek.m4 (gl_FUNC_LSEEK): Replace lseek on Darwin.
+	* modules/lseek (Depends-on): Depend on msvc-nothrow
+	and fstat only if needed.
+
 2021-11-11  Fabrice Fontaine(tiny change)
 
 	sigsegv: fix builds on microblazeel, or1k
diff --git a/doc/posix-functions/lseek.texi b/doc/posix-functions/lseek.texi
index 4a9d55dcf..2f8e2b587 100644
--- a/doc/posix-functions/lseek.texi
+++ b/doc/posix-functions/lseek.texi
@@ -9,6 +9,10 @@ Gnulib module: lseek
 Portability problems fixed by Gnulib:
 @itemize
 @item
+On some platforms, @code{lseek (fd, offset, SEEK_DATA)} returns a value
+greater than @code{offset} even when @code{offset} addresses data:
+macOS 12
+@item
 This function is declared in a different header file (namely, @code{})
 on some platforms:
 MSVC 14.
diff --git a/lib/lseek.c b/lib/lseek.c
index 0042546a8..7dcd6c9da 100644
--- a/lib/lseek.c
+++ b/lib/lseek.c
@@ -52,6 +52,22 @@ rpl_lseek (int fd, off_t offset, int whence)
   errno = ESPIPE;
   return -1;
 }
+#elif defined __APPLE__ && defined __MACH__ && defined SEEK_DATA
+  if (whence == SEEK_DATA)
+{
+  /* If OFFSET points to data, macOS lseek+SEEK_DATA returns the
+ start S of the first data region that begins *after* OFFSET,
+ where the region from OFFSET to S consists of possibly-empty
+ data followed by a possibly-empty hole.  To work around this
+ portability glitch, check whether OFFSET is within data by
+ using lseek+SEEK_HOLE, and if so return to OFFSET by using
+ lseek+SEEK_SET.  */
+  off_t next_hole = lseek (fd, offset, SEEK_HOLE);
+  if (next_hole < 0)
+return next_hole;
+  if (next_hole != offset)
+whence = SEEK_SET;
+}
 #else
   /* BeOS lseek mistakenly succeeds on pipes...  */
   struct stat statbuf;
diff --git a/m4/lseek.m4 b/m4/lseek.m4
index 0af63780a..faab09b73 100644
--- a/m4/lseek.m4
+++ b/m4/lseek.m4
@@ -1,4 +1,4 @@
-# lseek.m4 serial 11
+# lseek.m4 serial 12
 dnl Copyright (C) 2007, 2009-2021 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -59,7 +59,7 @@ AC_DEFUN([gl_FUNC_LSEEK],
  ;;
  esac
 ])
-  if test $gl_cv_func_lseek_pipe = no; then
+  if test "$gl_cv_func_lseek_pipe" = no; then
 REPLACE_LSEEK=1
 AC_DEFINE([LSEEK_PIPE_BROKEN], [1],
   [Define to 1 if lseek does not detect pipes.])
@@ -69,4 +69,10 @@ AC_DEFUN([gl_FUNC_LSEEK],
   if test $WINDOWS_64_BIT_OFF_T = 1; then
 REPLACE_LSEEK=1
   fi
+
+  dnl macOS SEEK_DATA is incompatible with other platforms.
+  case $host_os in
+darwin*)
+  REPLACE_LSEEK=1;;
+  esac
 ])
diff --git a/modules/lseek b/modules/lseek
index ced443123..f60809319 100644
--- a/modules/lseek
+++ b/modules/lseek
@@ -9,8 +9,8 @@ Depends-on:
 unistd

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Paul Eggert 

On 11/15/21 15:20, Pádraig Brady wrote:

I also have access to a macOS system, so I'll also test out
if there are ways to use SEEK_DATA there.


Could you try the latest savannah Git instead? I installed something 
into Gnulib that I hope lets coreutils use SEEK_DATA on macOS as before. 
The Gnulib workaround operates on macOS only, and requires an 
lseek+SEEK_HOLE and an lseek+SEEK_DATA where Linux, FreeBSD etc. need 
only lseek+SEEK_DATA, but that's good enough I would think to copy holes 
efficiently on macOS.


I plan to send another email about this shortly.

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Pádraig Brady 

On 15/11/2021 18:37, Sudhip Nashi via GNU coreutils Bug Reports wrote:



On Nov 15, 2021, at 11:33, Paul Eggert  wrote:

Is the source file on a ZFS file system by any chance? See my lseek comment 
below.


On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote:

stat64("/tmp/test\0", 0x16DDC36C0, 0x0) = 0 0
fstatat64(0xFFFE, 0x16DDC3C21, 0x16DDC2BA0) = 0 0
fstatat64(0xFFFE, 0x16DDC3C30, 0x16DDC2B10) = 0 0
open("/usr/bin/clear\0", 0x0, 0x0) = 3 0
fstat64(0x3, 0x16DDC2C30, 0x0) = 0 0
open("/tmp/test\0", 0x401, 0x0) = 4 0
fstat64(0x4, 0x16DDC2CC0, 0x0) = 0 0
fstat64(0x4, 0x16DDC2D50, 0x0) = 0 0
fcntl(0x3, 0x32, 0x16DDC3200) = 0 0
fcntl(0x4, 0x32, 0x16DDC2E00) = 0 0
unlink("/private/tmp/test\0", 0x0, 0x0) = 0 0


What's causing this use of "/private/tmp"? I don't see that in the GNU cp 
source code. Can you put a breakpoint on clonefileat and see what's calling it and what 
its arguments are?


clonefileat(0xFFFE, 0x16DDC3200, 0xFFFE) = -1 
Err#18
open("/private/tmp/test\0", 0x601, 0x81ED) = 5 0
close(0x5) = 0 0
open("/private/tmp/test\0", 0x2, 0x0) = 5 0
dup2(0x5, 0x4, 0x0) = 4 0
close(0x5) = 0 0
fchmod(0x4, 0x81ED, 0x0) = 0 0
fchown(0x4, 0x0, 0x0) = 0 0
futimes(0x4, 0x16DDC2DE0, 0x0) = 0 0
sysctl([CTL_HW, 7, 0, 0, 0, 0] (2), 0x207EC4068, 0x16DDC2A30, 0x0, 0x0) 
= 0 0
lseek(0x3, 0x0, 0x4) = -1 Err#6


That lseek call looks like OpenZFS bug 11900 
. If you're using ZFS, the bug really 
should be fixed in your ZFS implementation as it can affect programs other than coreutils 
and there's no easy workaround (other than to disable efficient copying). Is this something 
you can look into, or ask someone with macOS and/or ZFS expertise to look into? For more, 
see .


ftruncate(0x4, 0x1D770, 0x0) = 0 0
close(0x4) = 0 0
close(0x3) = 0 0


Turns out lseek is broken (or at least works differently) on macOS as well 
(https://lists.gnu.org/archive/html/bug-gnulib/2018-09/msg00054.html). Funny 
coincidence! I’ll take a better look later this week if I can and try to see 
what the exact problem is.


I saw on other report of failure on macOS.
I think we should disable the SEEK_DATA optimization there for now.
The attached does that.

I'll apply that later.
I also have access to a macOS system, so I'll also test out
if there are ways to use SEEK_DATA there.

thanks,
Pádraig
From e82670759e7eea3fb9faec99fcd94ad9f2fe03b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Mon, 15 Nov 2021 23:15:07 +
Subject: [PATCH] copy: avoid SEEK_DATA on macOS

* src/copy.c (infer_scantype): Don't probe for SEEK_DATA support
on __APPLE__ systems, as SEEK_DATA was seen to return ENXIO
inappropriately there.
* init.cfg (seek_data_capable_): Return failure on Darwin systems.
Addresses https://bugs.gnu.org/51857
---
 init.cfg   | 6 ++
 src/copy.c | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/init.cfg b/init.cfg
index b92f717f5..2ab607cf3 100644
--- a/init.cfg
+++ b/init.cfg
@@ -533,6 +533,12 @@ require_kill_group_()
 # which SEEK_DATA support exists.
 seek_data_capable_()
 {
+  # The SEEK_DATA implementation on macOS is not supported
+  if test "$(uname)" = Darwin; then
+warn_ 'seek_data_capable_: Darwin detected: assuming not SEEK_DATA capable'
+return 1
+  fi
+
   { python3 < /dev/null && PYTHON_=python3; } ||
   { python  < /dev/null && PYTHON_=python; }
 
diff --git a/src/copy.c b/src/copy.c
index f88bf3ed3..ecb37a02c 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -1100,7 +1100,7 @@ infer_scantype (int fd, struct stat const *sb,
  && ST_NBLOCKS (*sb) < sb->st_size / ST_NBLOCKSIZE))
 return PLAIN_SCANTYPE;
 
-#ifdef SEEK_HOLE
+#if defined SEEK_HOLE && !defined __APPLE__
   scan_inference->ext_start = lseek (fd, 0, SEEK_DATA);
   if (0 <= scan_inference->ext_start || errno == ENXIO)
 return LSEEK_SCANTYPE;
-- 
2.26.2

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Cameron Katri via GNU coreutils Bug Reports 
On Mon, Nov 15, 2021 at 01:33:44PM -0800, Paul Eggert wrote:
> On 11/15/21 09:40, Cameron Katri wrote:
> 
> Did you build vanilla coreutils 9.0 yourself? If so, what commands did you
> you use to build it, exactly? If not, who built coreutils and how did they
> configure and/or modify it? I worry that we're looking at a version of
> coreutils cp that has been modified somehow, or that you're dtrussing the
> wrong cp somehow.

I forgot that I had a patch to enable reflink on APFS, I just rebuilt a
vanilla coreutils with just ./configure && make and the issue persists.
Sorry about that, here is the correct dtruss:

cameron in Documents/coreutils-9.0/src at build
\> sudo dtruss ./cp /usr/bin/clear /tmp/test
SYSCALL(args)= return
access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0) = -1 Err#2
bsdthread_register(0x1AEC802C8, 0x1AEC802BC, 0x4000) = 1073742303 0
shm_open(0x1AEB48F55, 0x0, 0x4158000)= 3 0
fstat64(0x3, 0x16BCA6130, 0x0)   = 0 0
mmap(0x0, 0x4000, 0x1, 0x40001, 0x3, 0x0)= 0x104298000 0
close(0x3)   = 0 0
ioctl(0x2, 0x4004667A, 0x16BCA61DC)  = 0 0
mprotect(0x1042A4000, 0x4000, 0x0)   = 0 0
mprotect(0x1042B, 0x4000, 0x0)   = 0 0
mprotect(0x1042B4000, 0x4000, 0x0)   = 0 0
mprotect(0x1042C, 0x4000, 0x0)   = 0 0
mprotect(0x1042C4000, 0x4000, 0x0)   = 0 0
mprotect(0x1042D, 0x4000, 0x0)   = 0 0
mprotect(0x10429C000, 0x90, 0x1) = 0 0
mprotect(0x10429C000, 0x90, 0x3) = 0 0
mprotect(0x10429C000, 0x90, 0x1) = 0 0
mprotect(0x1042D4000, 0x4000, 0x1)   = 0 0
mprotect(0x1042D8000, 0x90, 0x1) = 0 0
mprotect(0x1042D8000, 0x90, 0x3) = 0 0
mprotect(0x1042D8000, 0x90, 0x1) = 0 0
mprotect(0x10429C000, 0x90, 0x3) = 0 0
mprotect(0x10429C000, 0x90, 0x1) = 0 0
mprotect(0x1042D4000, 0x4000, 0x3)   = 0 0
mprotect(0x1042D4000, 0x4000, 0x1)   = 0 0
objc_bp_assist_cfg_np(0x1AEB103C0, 0x80201048, 0x0)  = -1 
Err#5
issetugid(0x0, 0x0, 0x0) = 0 0
getentropy(0x16BCA5FF8, 0x20, 0x0)   = 0 0
getentropy(0x16BCA6048, 0x40, 0x0)   = 0 0
getpid(0x0, 0x0, 0x0)= 91358 0
stat64("/AppleInternal\0", 0x16BCA6740, 0x0) = -1 Err#2
csops_audittoken(0x164DE, 0x7, 0x16BCA6270)  = 0 0
proc_info(0x2, 0x164DE, 0xD) = 64 0
csops_audittoken(0x164DE, 0x7, 0x16BCA6330)  = 0 0
sysctlbyname(kern.osvariant_status, 0x15, 0x16BCA67A8, 0x16BCA67A0, 0x0)
 = 0 0
csops(0x164DE, 0x0, 0x16BCA67CC) = 0 0
mprotect(0x10419, 0x10, 0x1) = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_COLLATE\0", 0x0, 0x0)   
 = 3 0
fcntl_nocancel(0x3, 0x3, 0x0)= 0 0
getrlimit(0x1008, 0x16BCA7178, 0x0)  = 0 0
fstat64(0x3, 0x16BCA70F0, 0x0)   = 0 0
read_nocancel(0x3, "1.1A\n\0", 0x1000)   = 2086 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_CTYPE\0", 0x0, 0x0) 
 = 3 0
fcntl_nocancel(0x3, 0x3, 0x0)= 0 0
fstat64(0x3, 0x16BCA7220, 0x0)   = 0 0
fstat64(0x3, 0x16BCA7010, 0x0)   = 0 0
lseek(0x3, 0x0, 0x1) = 0 0
lseek(0x3, 0x0, 0x0) = 0 0
read_nocancel(0x3, "RuneMagAUTF-8\0", 0x1000)= 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "@\004\211\0", 0xF5D0)= 62928 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_MONETARY\0", 0x0, 0x0)  
 = 3 0
fstat64(0x3, 0x16BCA7240, 0x0)   = 0 0
read_nocancel(0x3, "USD \n$\n.\n,\n3;3\n\n-\n2\n2\n1\n0\n1\n0\n1\n1\n(\0", 
0x22) = 34 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_NUMERIC\0", 0x0, 0x0)   
 = 3 0
fstat64(0x3, 0x16BCA7240, 0x0)   = 0 0
read_nocancel(0x3, ".\n,\n3;3\n@$\b\0", 0x8) = 8 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_TIME\0", 0x0, 0x0)  
 = 3 0
fstat64(0x3, 0x16BCA7250, 0x0)   = 0 0
read_nocancel(0x3, 
"Jan\nFeb\nMar\nApr\nMay\nJun\nJul\nAug\nSep\nOct\nNov\nDec\nJanuary\nFebruary\nMarch\nApril\nMay\nJune\nJuly\nAugust\nSeptember\nOctober\nNovember\nDecember\nSun\nMon\nTue\nWed\nThu\nFri\nSat\nSunday\nMonday\nTuesday\nWednesday\nThursday\nFriday\nSaturday\n%H:%M:%S\n%m/%d/%Y\n%a
 %b %e %X %Y\nAM\nP", 0x179)= 377 0

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Paul Eggert 

On 11/15/21 09:40, Cameron Katri wrote:


No, this is one APFS (Apple File System).


OK, so ZFS is not involved.



unlink("/private/tmp/test\0", 0x0, 0x0)= 0 0


What's causing this use of "/private/tmp"? I don't see that in the GNU cp
source code. Can you put a breakpoint on clonefileat and see what's calling
it and what its arguments are?


On macOS, `/tmp` is a symlink to `/private/tmp`.


Fine, but why would 'cp' remove /private/tmp/test when you told it to 
copy to /tmp/test? I see no reason why it would expand the symlink by 
hand, nor why it would remove the destination file even if it calculated 
that /tmp/test and /private/tmp/test were the same file (it's not 
supposed to do that).


And why would 'cp' invoke clonefileat? Coreutils cp's source code does 
not mention clonefileat anywhere.


Something very odd is going on here.

Did you build vanilla coreutils 9.0 yourself? If so, what commands did 
you you use to build it, exactly? If not, who built coreutils and how 
did they configure and/or modify it? I worry that we're looking at a 
version of coreutils cp that has been modified somehow, or that you're 
dtrussing the wrong cp somehow.

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Sudhip Nashi via GNU coreutils Bug Reports 


> On Nov 15, 2021, at 11:33, Paul Eggert  wrote:
> 
> Is the source file on a ZFS file system by any chance? See my lseek comment 
> below.
> 
>> On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote:
>> 
>> stat64("/tmp/test\0", 0x16DDC36C0, 0x0) = 0 0
>> fstatat64(0xFFFE, 0x16DDC3C21, 0x16DDC2BA0) = 0 0
>> fstatat64(0xFFFE, 0x16DDC3C30, 0x16DDC2B10) = 0 0
>> open("/usr/bin/clear\0", 0x0, 0x0) = 3 0
>> fstat64(0x3, 0x16DDC2C30, 0x0) = 0 0
>> open("/tmp/test\0", 0x401, 0x0) = 4 0
>> fstat64(0x4, 0x16DDC2CC0, 0x0) = 0 0
>> fstat64(0x4, 0x16DDC2D50, 0x0) = 0 0
>> fcntl(0x3, 0x32, 0x16DDC3200) = 0 0
>> fcntl(0x4, 0x32, 0x16DDC2E00) = 0 0
>> unlink("/private/tmp/test\0", 0x0, 0x0) = 0 0
> 
> What's causing this use of "/private/tmp"? I don't see that in the GNU cp 
> source code. Can you put a breakpoint on clonefileat and see what's calling 
> it and what its arguments are?
> 
>> clonefileat(0xFFFE, 0x16DDC3200, 0xFFFE) = 
>> -1 Err#18
>> open("/private/tmp/test\0", 0x601, 0x81ED) = 5 0
>> close(0x5) = 0 0
>> open("/private/tmp/test\0", 0x2, 0x0) = 5 0
>> dup2(0x5, 0x4, 0x0) = 4 0
>> close(0x5) = 0 0
>> fchmod(0x4, 0x81ED, 0x0) = 0 0
>> fchown(0x4, 0x0, 0x0) = 0 0
>> futimes(0x4, 0x16DDC2DE0, 0x0) = 0 0
>> sysctl([CTL_HW, 7, 0, 0, 0, 0] (2), 0x207EC4068, 0x16DDC2A30, 0x0, 0x0)  
>>= 0 0
>> lseek(0x3, 0x0, 0x4) = -1 Err#6
> 
> That lseek call looks like OpenZFS bug 11900 
> . If you're using ZFS, the bug 
> really should be fixed in your ZFS implementation as it can affect programs 
> other than coreutils and there's no easy workaround (other than to disable 
> efficient copying). Is this something you can look into, or ask someone with 
> macOS and/or ZFS expertise to look into? For more, see 
> .
> 
>> ftruncate(0x4, 0x1D770, 0x0) = 0 0
>> close(0x4) = 0 0
>> close(0x3) = 0 0

Turns out lseek is broken (or at least works differently) on macOS as well 
(https://lists.gnu.org/archive/html/bug-gnulib/2018-09/msg00054.html). Funny 
coincidence! I’ll take a better look later this week if I can and try to see 
what the exact problem is.

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Cameron Katri via GNU coreutils Bug Reports 
On Mon, Nov 15, 2021 at 09:33:21AM -0800, Paul Eggert wrote:
> Is the source file on a ZFS file system by any chance? See my lseek comment
> below.

No, this is one APFS (Apple File System).

> 
> On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote:
> 
> > stat64("/tmp/test\0", 0x16DDC36C0, 0x0)  = 0 0
> > fstatat64(0xFFFE, 0x16DDC3C21, 0x16DDC2BA0)  = 0 0
> > fstatat64(0xFFFE, 0x16DDC3C30, 0x16DDC2B10)  = 0 0
> > open("/usr/bin/clear\0", 0x0, 0x0)   = 3 0
> > fstat64(0x3, 0x16DDC2C30, 0x0)   = 0 0
> > open("/tmp/test\0", 0x401, 0x0)  = 4 0
> > fstat64(0x4, 0x16DDC2CC0, 0x0)   = 0 0
> > fstat64(0x4, 0x16DDC2D50, 0x0)   = 0 0
> > fcntl(0x3, 0x32, 0x16DDC3200)= 0 0
> > fcntl(0x4, 0x32, 0x16DDC2E00)= 0 0
> > unlink("/private/tmp/test\0", 0x0, 0x0)  = 0 0
> 
> What's causing this use of "/private/tmp"? I don't see that in the GNU cp
> source code. Can you put a breakpoint on clonefileat and see what's calling
> it and what its arguments are?

On macOS, `/tmp` is a symlink to `/private/tmp`.

> 
> > clonefileat(0xFFFE, 0x16DDC3200, 0xFFFE)
> >  = -1 Err#18
> > open("/private/tmp/test\0", 0x601, 0x81ED)   = 5 0
> > close(0x5)   = 0 0
> > open("/private/tmp/test\0", 0x2, 0x0)= 5 0
> > dup2(0x5, 0x4, 0x0)  = 4 0
> > close(0x5)   = 0 0
> > fchmod(0x4, 0x81ED, 0x0) = 0 0
> > fchown(0x4, 0x0, 0x0)= 0 0
> > futimes(0x4, 0x16DDC2DE0, 0x0)   = 0 0
> > sysctl([CTL_HW, 7, 0, 0, 0, 0] (2), 0x207EC4068, 0x16DDC2A30, 0x0, 0x0) 
> >  = 0 0
> > lseek(0x3, 0x0, 0x4) = -1 Err#6
> 
> That lseek call looks like OpenZFS bug 11900
> . If you're using ZFS, the bug
> really should be fixed in your ZFS implementation as it can affect programs
> other than coreutils and there's no easy workaround (other than to disable
> efficient copying). Is this something you can look into, or ask someone with
> macOS and/or ZFS expertise to look into? For more, see
> .
> 
> > ftruncate(0x4, 0x1D770, 0x0) = 0 0
> > close(0x4)   = 0 0
> > close(0x3)   = 0 0

-- 
Cameron Katri
Email: m...@cameronkatri.com
PGP Fingerprint: 7D3B36CEA40FCC2181FB6DCDBAFFD97826540F1C


signature.asc
Description: PGP signature

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Paul Eggert 
Is the source file on a ZFS file system by any chance? See my lseek 
comment below.


On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote:


stat64("/tmp/test\0", 0x16DDC36C0, 0x0)= 0 0
fstatat64(0xFFFE, 0x16DDC3C21, 0x16DDC2BA0)  = 0 0
fstatat64(0xFFFE, 0x16DDC3C30, 0x16DDC2B10)  = 0 0
open("/usr/bin/clear\0", 0x0, 0x0) = 3 0
fstat64(0x3, 0x16DDC2C30, 0x0)   = 0 0
open("/tmp/test\0", 0x401, 0x0)= 4 0
fstat64(0x4, 0x16DDC2CC0, 0x0)   = 0 0
fstat64(0x4, 0x16DDC2D50, 0x0)   = 0 0
fcntl(0x3, 0x32, 0x16DDC3200)= 0 0
fcntl(0x4, 0x32, 0x16DDC2E00)= 0 0
unlink("/private/tmp/test\0", 0x0, 0x0)= 0 0


What's causing this use of "/private/tmp"? I don't see that in the GNU 
cp source code. Can you put a breakpoint on clonefileat and see what's 
calling it and what its arguments are?



clonefileat(0xFFFE, 0x16DDC3200, 0xFFFE)
 = -1 Err#18
open("/private/tmp/test\0", 0x601, 0x81ED) = 5 0
close(0x5)   = 0 0
open("/private/tmp/test\0", 0x2, 0x0)  = 5 0
dup2(0x5, 0x4, 0x0)  = 4 0
close(0x5)   = 0 0
fchmod(0x4, 0x81ED, 0x0) = 0 0
fchown(0x4, 0x0, 0x0)= 0 0
futimes(0x4, 0x16DDC2DE0, 0x0)   = 0 0
sysctl([CTL_HW, 7, 0, 0, 0, 0] (2), 0x207EC4068, 0x16DDC2A30, 0x0, 0x0) 
 = 0 0
lseek(0x3, 0x0, 0x4) = -1 Err#6


That lseek call looks like OpenZFS bug 11900 
. If you're using ZFS, the 
bug really should be fixed in your ZFS implementation as it can affect 
programs other than coreutils and there's no easy workaround (other than 
to disable efficient copying). Is this something you can look into, or 
ask someone with macOS and/or ZFS expertise to look into? For more, see 
.



ftruncate(0x4, 0x1D770, 0x0) = 0 0
close(0x4)   = 0 0
close(0x3)   = 0 0

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Cameron Katri via GNU coreutils Bug Reports 


> On Nov 15, 2021, at 10:09 AM, Pádraig Brady  wrote:
> 
> On 15/11/2021 04:02, Sudhip Nashi via GNU coreutils Bug Reports wrote:
>> Hello,
>> Cross-filesystem copying seems to have been broken in the latest coreutils 
>> release on macOS. Running a command like ‘cp /usr/bin/clear /tmp/test’ 
>> appears to return successfully, but if one analyzes /tmp/test, it’s filled 
>> with NULL characters. However, copying works fine when the source and 
>> destination file are on the same filesystem. Do you know what might be 
>> causing this?
>> Thanks in advance,
>> Sudhip Nashi
> 
> What are the source and dest file system types?
> Could you send the output of `sudo dtruss cp /usr/bin/clear /tmp/test`?
> I suspect SEEK_DATA may have issues on nacOS,
> as usage of that is new in coreutils 9.0.
> 
> thanks,
> Pádraig

Here yo go:

sudo dtruss ./src/cp /usr/bin/clear /tmp/test
SYSCALL(args)= return
access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0) = -1 Err#2
bsdthread_register(0x1AEC802C8, 0x1AEC802BC, 0x4000) = 1073742303 0
shm_open(0x1AEB48F55, 0x0, 0xB821D000)   = 3 0
fstat64(0x3, 0x16DDC2070, 0x0)   = 0 0
mmap(0x0, 0x4000, 0x1, 0x40001, 0x3, 0x0)= 0x10217 0
close(0x3)   = 0 0
ioctl(0x2, 0x4004667A, 0x16DDC211C)  = 0 0
mprotect(0x1021A, 0x4000, 0x0)   = 0 0
mprotect(0x1021AC000, 0x4000, 0x0)   = 0 0
mprotect(0x1021B, 0x4000, 0x0)   = 0 0
mprotect(0x1021BC000, 0x4000, 0x0)   = 0 0
mprotect(0x1021C, 0x4000, 0x0)   = 0 0
mprotect(0x1021CC000, 0x4000, 0x0)   = 0 0
mprotect(0x102174000, 0x90, 0x1) = 0 0
mprotect(0x102174000, 0x90, 0x3) = 0 0
mprotect(0x102174000, 0x90, 0x1) = 0 0
mprotect(0x10217C000, 0x4000, 0x1)   = 0 0
mprotect(0x1021D, 0x90, 0x1) = 0 0
mprotect(0x1021D, 0x90, 0x3) = 0 0
mprotect(0x1021D, 0x90, 0x1) = 0 0
mprotect(0x102174000, 0x90, 0x3) = 0 0
mprotect(0x102174000, 0x90, 0x1) = 0 0
mprotect(0x10217C000, 0x4000, 0x3)   = 0 0
mprotect(0x10217C000, 0x4000, 0x1)   = 0 0
objc_bp_assist_cfg_np(0x1AEB103C0, 0x80201048, 0x0)  = -1 
Err#5
issetugid(0x0, 0x0, 0x0) = 0 0
getentropy(0x16DDC1EC8, 0x20, 0x0)   = 0 0
getentropy(0x16DDC1F18, 0x40, 0x0)   = 0 0
getpid(0x0, 0x0, 0x0)= 4661 0
stat64("/AppleInternal\0", 0x16DDC2680, 0x0) = -1 Err#2
csops_audittoken(0x1235, 0x7, 0x16DDC21B0)   = 0 0
proc_info(0x2, 0x1235, 0xD)  = 64 0
csops_audittoken(0x1235, 0x7, 0x16DDC2270)   = 0 0
sysctlbyname(kern.osvariant_status, 0x15, 0x16DDC26E8, 0x16DDC26E0, 0x0)
 = 0 0
csops(0x1235, 0x0, 0x16DDC270C)  = 0 0
geteuid(0x0, 0x0, 0x0)   = 0 0
getuid(0x0, 0x0, 0x0)= 0 0
sysctl([CTL_KERN, 14, 1, 4661, 0, 0] (4), 0x16DDC0C00, 0x16DDC0BE8, 0x0, 0x0)   
 = 0 0
gettid(0x16DDC0EE0, 0x16DDC0EE4, 0x0)= -1 Err#3
geteuid(0x0, 0x0, 0x0)   = 0 0
getegid(0x0, 0x0, 0x0)   = 0 0
csops(0x1235, 0x0, 0x16DDC1C24)  = 0 0
gettid(0x16DDC0EB0, 0x16DDC0EB4, 0x0)= -1 Err#3
geteuid(0x0, 0x0, 0x0)   = 0 0
getegid(0x0, 0x0, 0x0)   = 0 0
mprotect(0x102068000, 0x10, 0x1) = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_COLLATE\0", 0x0, 0x0)   
 = 3 0
fcntl_nocancel(0x3, 0x3, 0x0)= 0 0
getrlimit(0x1008, 0x16DDC2F98, 0x0)  = 0 0
fstat64(0x3, 0x16DDC2F10, 0x0)   = 0 0
read_nocancel(0x3, "1.1A\n\0", 0x1000)   = 2086 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_CTYPE\0", 0x0, 0x0) 
 = 3 0
fcntl_nocancel(0x3, 0x3, 0x0)= 0 0
fstat64(0x3, 0x16DDC3040, 0x0)   = 0 0
fstat64(0x3, 0x16DDC2E30, 0x0)   = 0 0
lseek(0x3, 0x0, 0x1) = 0 0
lseek(0x3, 0x0, 0x0) = 0 0
read_nocancel(0x3, "RuneMagAUTF-8\0", 0x1000)= 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "@\004\211\0", 0xF5D0)= 62928 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_MONETARY\0", 0x0, 0x0)  
 = 3 0
fstat64(0x3, 0x16DDC3060, 0x0)   = 0 0
read_nocancel(0x3, "USD \n$\n.\n,\n3;3\n\n-\n2\n2\n1\n0\n1\n0\n1\n1\n(\0", 
0x22) = 34 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_NUMERIC\0",

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-15 Thread Pádraig Brady 

On 15/11/2021 04:02, Sudhip Nashi via GNU coreutils Bug Reports wrote:

Hello,

Cross-filesystem copying seems to have been broken in the latest coreutils 
release on macOS. Running a command like ‘cp /usr/bin/clear /tmp/test’ appears 
to return successfully, but if one analyzes /tmp/test, it’s filled with NULL 
characters. However, copying works fine when the source and destination file 
are on the same filesystem. Do you know what might be causing this?

Thanks in advance,
Sudhip Nashi




What are the source and dest file system types?
Could you send the output of `sudo dtruss cp /usr/bin/clear /tmp/test`?
I suspect SEEK_DATA may have issues on nacOS,
as usage of that is new in coreutils 9.0.

thanks,
Pádraig

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

2021-11-14 Thread Sudhip Nashi via GNU coreutils Bug Reports 
Hello,

Cross-filesystem copying seems to have been broken in the latest coreutils 
release on macOS. Running a command like ‘cp /usr/bin/clear /tmp/test’ appears 
to return successfully, but if one analyzes /tmp/test, it’s filled with NULL 
characters. However, copying works fine when the source and destination file 
are on the same filesystem. Do you know what might be causing this?

Thanks in advance,
Sudhip Nashi