Follow-up Comment #3, bug #68223 (group findutils): There are no patches for findutils in the macports port (see https://github.com/macports/macports-ports/blob/master/sysutils/findutils/Portfile).
Unfortunately, I'm not familiar with dtruss, and its output is wierd. Ah, it makes the process's stdout go to stderr along with its own output. The full output (including 1.2 million paths from gfind's stdout) is at https://raf.org/tmp/gfind.dtruss.gz (7.4MB). I removed all the paths (lines starting with "/") which leaves some partial paths in the output. Not sure why, but I think some dtruss/dtrace error messages got mixed in. Also, some paths on macOS contain "\r" so that might make it messy. You might have to check the big file to verify that. Anyway, the file with (mostly) just the syscalls is at https://raf.org/tmp/gfind.dtruss.syscalls.gz (49KB). I'll remove the above links eventually, but not anytime soon. The tail end of that file looks like this: fcntl(0x8, 0x43, 0x0) = 4 0 openat(0x8, "A\0", 0x1120104, 0x0) = 6 0 fstat64(0x6, 0x16F5532D0, 0x0) = 0 0 fcntl_nocancel(0x6, 0x2, 0x1) = 0 0 fstatfs64(0x6, 0x16F552A00, 0x0) = 0 0 getdirentries64(0x6, 0x131809200, 0x800) = 104 0 fstat64(0x6, 0x121604760, 0x0) = 0 0 fcntl(0x6, 0x43, 0x3) = 9 0 close_nocancel(0x6) = 0 0 close(0x4) = 0 0 fcntl(0x9, 0x43, 0x0) = 4 0 write_nocancel(0x1, "form/Developer/SDKs/MacOSX.sdk/System/Library/PrivateFrameworks/SiriCore.framework/.BC.D_9BBOBW\n/System/Volumes/Data/Library/InstallerSandboxes/.PKInstallSandboxManager/E385B0EA-C9BF-45C0-9950-788030D0E975.activeSandbox/Root/Applications/Xcode.app/Contents", 0x1000) = 4096 0 close(0x9) = 0 0 close(0x4) = 0 0 fcntl(0x8, 0x43, 0x0) = 4 0 close(0x8) = 0 0 close(0x4) = 0 0 fcntl(0x7, 0x43, 0x0) = 4 0 close(0x7) = 0 0 close(0x4) = 0 0 fcntl(0x5, 0x43, 0x0) = 4 0 fstatat64(0x5, 0x12164C270, 0x12164C1E0) = 0 0 openat(0x5, "MultitouchSupport.framework\0", 0x1120104, 0x0) = 6 0 fstat64(0x6, 0x16F5532D0, 0x0) = 0 0 fcntl_nocancel(0x6, 0x2, 0x1) = 0 0 fstatfs64(0x6, 0x16F552A00, 0x0) = 0 0 getdirentries64(0x6, 0x131809200, 0x800) = 144 0 fstat64(0x6, 0x12164C1E0, 0x0) = 0 0 fcntl(0x6, 0x43, 0x3) = 7 0 close_nocancel(0x6) = 0 0 fstatat64(0x0, 0x0, 0x0) = 0 0 anager/E385B0EA-C9BF-45C0-9950-788030D0E975.activeSandbox/Root/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/IOKit.framework/Versions gfind: failed to read file names from file system at or below ‘/’: No such file or directory dtrace: 84215 dynamic variable drops with non-empty dirty list workq_kernreturn(0x100, 0x16F5DAB80, 0x1) = 0 Err#-2 I'm not sure if that's helpful. Maybe the complete output will help more(?). This died after about 1.2 million files out of 7.1 million files. By the way, my rawhide (rh) program doesn't have this problem. It seems to output most of the files, and doesn't encounter any errors (just using opendir/readdir/closedir), but it doesn't exactly match the output of the system-supplied version of find. On this system, the system find finds 7126481 files, while rh only finds 6774744. I think it relates to the new use of firmlinks that started in macOS-10.15 to achieve an overlay/union file system for the readonly parts of the operating system (GNU find and my rh match on my macOS-10.14 laptop). These firmlinks exist in /System/Volumes/Data. But the differences are not just that, so I don't understand why there is a difference. If it were just firmlink-related, I would expect the system find to maybe not report both appearances of files, and rh to report both appearances (which would be acceptable), but that's not what's happening. Something wierd is going on. I hope this helps. Let me know if you need anything more. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?68223> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
