findutils: cannot use locate; updatedb apparently fails to do anything useful!

[seamusdemora (Seamus)]

I've just installed 'findutils' to help me verify the location of files I've installed with macPorts. Unfortunately, while I manually tracked the file ('libaacs.a') down (in '/opt/local/lib'), "locate" refuses to find anything.

"updatedb" reports the following gibberish:

sudo /opt/local/libexec/gnubin/updatedb
gfind: '/Library/Caches/com.apple.amsengagementd.classicdatavault': Operation not permitted
gfind: '/Library/Caches/com.apple.aneuserd': Operation not permitted
gfind: '/Library/Caches/com.apple.aned': Operation not permitted
gfind: '/System/Library/AssetsV2/com_apple_MobileAsset_UAF_FM_Overrides': Operation not permitted
gfind: '/System/Volumes/Data/Library/Caches/com.apple.amsengagementd.classicdatavault': Operation not permitted
gfind: '/System/Volumes/Data/Library/Caches/com.apple.aneuserd': Operation not permitted
gfind: '/System/Volumes/Data/Library/Caches/com.apple.aned': Operation not permitted
gfind: failed to read file names from file system at or below '/': No such file or directory

What must I do to get "locate" to work, and "updatedb" to index my filesystem properly??

I've read 'man updatedb', but it provided no insight for me. One thing that's particularly confusing is the location of the database. 'man updatedb' says, "... the default is /var/cache/locate/locatedb", but that doesn't exist on my system. I've also read some stuff in StackExchange suggesting that the problem may be Apple's native 'locate' and its database getting mixed up with the GNU/MacPorts version of 'locate' and its database.

Apologies if this seems like a lame request... I've tried to find a solution, but come up empty-handed! And PLEASE let me know if additional details are needed.

[seamusdemora (Seamus)]

Some added information: This is not the Mac I ordinarily use - it belongs to my wifey-poo :) She apparently recently upgraded the OS from "whatever" to Sequoia. I installed MacPorts on this machine when it was still running the "whatever" version of the OS :(

After re-reading some of the documentation, I have noted that either a "migration" or an "un-install" are recommended (required?) for MacPorts when upgrading the OS; further, the "migration" option must apparently be done BEFORE the OS upgrade. IOW - the failure I've reported could be entirely down to my lack of awareness!

However: On my Mac (Ventura OS) I seem to have exactly the same issue with the GNU version of 'locate' - also installed through MacPorts. This is particularly problematic for me because the "native"/Apple-supplied version of 'locate' also has issues that have effectively rendered it useless for my needs.

All that said: I would truly appreciate some advice, or a recommended course of action, or a status update on this ticket from one of the maintainers. Again - I would love to "help", so please let me know if I can do anything at all to move this issue toward resolution.

Best Rgds, ~S

[ryandesign (Ryan Carsten Schmidt)]

Migration is required if you want to continue using MacPorts to install or upgrade ports; if you just want to continue to use the versions of the ports you installed before, you can probably continue to do that without migrating.

Migration is done after upgrading the OS. In the past, you had to manually record some information while still in your old OS before upgrading, but these days upgrading is done automatically by running sudo port migrate and no preparation on the old OS version is necessary.

The maintainer Chris hasn't been very active here lately so you might not get a response from him.

Would using the macOS version of locate, and ignoring/uninstalling the MacPorts one, meet your needs?

[seamusdemora (Seamus)]

Thank you for the update/status!

sudo port migrate ran just fine.

If it weren't such a damn bodge, macOS locate might be OK; but as it is, there are a couple of issues:

1. There's a launchctl job that runs /usr/libexec/locate.updatedb to update the database, but it's scheduled for once-a-week updates, and is on a "Protected" volume so the schedule cannot be changed.

2. Apple has also put the locate-updatedb script on a read-only volume. Not only can it NOT be changed, but it fails to run successfully from the command line!?

I've developed "work-arounds" that kinda'/sorta' work for both of these, but I hate having to kludge around Apple's flawed obsessions to coax a 30 year-old tool into working as it should. At any rate, I use locate on my Linux boxes, and have no problems with it. I can appreciate things won't be as smooth on macOS, but that final error message leads me to believe that GNU locate can see nothing at all - at or below /.

Knowing that Chris is inactive, I'll try to dig a bit deeper. If I discover anything useful, I'll post it here.

[seamusdemora (Seamus)]

I've done a little bit of research, and a few simple experiments:

​The research used this search term: macos GNU find: failed to read file names from file system at or below '/'

Perhaps noteworthy is that some have reported this issue first arose in the "10.15/Catalina" release of macOS. This is consistent with my experience: On my macOS 10.14/Mojave machine (I never upgrade macOS!) I can still successfully run sudo /opt/local/bin/gupdatedb; which is to say that /opt/local/var/locatedb is actually updated as new files are created, and old files are removed. Specifically:

$ sudo /opt/local/bin/gupdatedb
  # throws errors for folders in '/private/var/...'
  # but this can be corrected with:
$ sudo /opt/local/bin/gupdatedb --prunepaths='/private/var'
$
  # ↑  "look ma, no errors"  :)

However - as noted previously, sudo /opt/local/bin/gupdatedb fails completely on my "13.7.7/Ventura" release of macOS as implied by the final error: re. ... at or below '/'

% sudo /opt/local/bin/gupdatedb
gfind: '/Library/Caches/com.apple.aned': Operation not permitted
gfind: '/System/Library/Templates/Data/private/var/db/oah': Operation not permitted
gfind: '/System/Volumes/Data/Library/Caches/com.apple.aned': Operation not permitted
gfind: failed to read file names from file system at or below '/': No such file or directory

I checked the --versions on both 10.14/Mojave and 13.7.7/Ventura; both reported as (GNU findutils) 4.10.0.

By "complete failure" I mean that, after running the above command, the database file mod time is updated, and its size changes, BUT the database itself is never updated with new files:

% ls -l /opt/local/var/locatedb
-rw-r--r-- 1 root wheel 10752111 Feb  8 13:52 /opt/local/var/locatedb

% ls -l ezpl.m3u
-rw-r--r-- 1 seamus staff 10626 Jul 28  2025 ezpl.m3u

% /opt/local/bin/glocate ezpl.m3u

%

All of which seems to establish that in recent releases of macOS /opt/local/bin/gfind is somehow being blocked from searching the root folder. However, it's unclear to me why or how the OS manages to do this, because:

% /opt/local/bin/gls /
Applications  Library  System  Users  Volumes  bin  cores  dev	etc  home  opt	private  sbin  tmp  usr  var 

% /opt/local/bin/gls /bin
'['     cat     cp    dash   dd   echo	 expr	    kill   launchctl   ln   mkdir   pax   pwd	     rm      sh      stty   tcsh   unlink      zsh
 bash   chmod   csh   date   df   ed	 hostname   ksh    link        ls   mv	    ps	  realpath   rmdir   sleep   sync   test   wait4path

  # IOW, gls can list all files in "protected" folders... why is 'gfind' disallowed???

First step was to ensure that /opt/local/bin/gfind is included in 'System Settings, Full Disk Access'; I checked this, and it was!

Afterwards, a few simple experiments were run. These led me to wonder if the apparent macOS restrictions are as severe as they first appear. IOW: 'gfind' remains able to access folders below root '/'. Could /opt/local/bin/gupdatedb be modified to use /opt/local/bin/gfind on each individual folder below root '/' ?? For example(s):

% sudo /opt/local/bin/gfind /bin -name "launchctl"
/bin/launchctl 

  # or, alternatively:

% /opt/local/bin/gfind /bin -type f
/bin/cat
/bin/echo
/bin/launchctl
/bin/df
/bin/pwd
/bin/test
  # ... etc, etc

% sudo /opt/local/bin/gfind /sbin -name "mpioutil"
/sbin/mpioutil

  # And then there is this situation:

% cd /private/var/protected/xprotect
% sudo /opt/local/bin/gfind . -name "XPdb-wal"
./XPdb-wal
% sudo /opt/local/bin/gfind /private/var/protected/xprotect -name "XPdb-wal"
/private/var/protected/xprotect/XPdb-wal

  # but ...

% sudo /opt/local/bin/gfind /private/var/protected -name "XPdb-wal"
/private/var/protected/xprotect/XPdb-wal
gfind: ‘/private/var/protected/trustd/private’: Operation not permitted

% sudo /opt/local/bin/gls -l /private/var/protected/trustd/private
gls: cannot open directory '/private/var/protected/trustd/private': Operation not permitted

  # which shows that there are also limits to 'gls' 
  # but further suggests an iterative approach w/ 'gfind' might actually "find" most files 

I can imagine that it may be impractical for the MacPorts team to re-write chunks of GNU's find utility to accommodate the gross aberrations Apple has created. Nevertheless, I submit this as "food for thought". In the meantime, I'll make an effort to contact GNU's 'findutils' team, and get their feedback.

[seamusdemora (Seamus)]

After all of the above, it finally dawned on me to try this "experiment":

% /opt/local/bin/gfind / -type f | less    # also ran w/ sudo...

/opt/local/bin/gfind works!! ...and now, I am totally confused as to why /opt/local/libexec/gnubin/updatedb fails!

[pierow2k]

seamusdemora (Seamus) said:

However, it's unclear to me why or how the OS manages to do this...

macOS ​System Integrity Protection (SIP) prevents the tool from accessing critical system directories like /System or /Library. GNU find attempts to traverse protected directories that standard users cannot access.

To fix this, you just explicitly exclude these directories using the --prunepaths option.

Example:

sudo \
  /opt/local/bin/gupdatedb \
    --localpaths=/ \
    --prunepaths="/Volumes /System /Library"

Once the database update completes, use glocate to search for items within the database.

[seamusdemora (Seamus)]

Replying to pierow2k:

seamusdemora (Seamus) said:

However, it's unclear to me why or how the OS manages to do this...

macOS ​System Integrity Protection (SIP) prevents the tool from accessing critical system directories like /System or /Library. GNU find attempts to traverse protected directories that standard users cannot access.

To fix this, you just explicitly exclude these directories using the --prunepaths option.

Example:

sudo \
  /opt/local/bin/gupdatedb \
    --localpaths=/ \
    --prunepaths="/Volumes /System /Library"

Once the database update completes, use glocate to search for items within the database.

Appreciate the feedback, but let me ask: "Are you submitting this as a 'solution' to the bug report I've filed?"

If so, I think it falls a bit short. The problem I see is being able to accurately list everything covered by SIP. AFAIK, Apple certainly doesn't provide this data! So - how is one to determine - on an arbitrary OS version - which folders are covered by SIP?

A second problem (again, strictly from my perspective) is that this is supposed to be a 'port' designed for the macOS. If it's true (as you imply) that SIP is the issue, it seems to me this should be addressed in the code for the port - instead of just failing completely to update the database, the port code should offer something besides complete and silent failure.

That's my opinion... what's yours?

Oh - FWIW, there's a thread on the GNU mailing list for 'findutils' that discusses this issue, but it doesn't seem to be going anywhere fast. AIUI, this lack of progress may be due to the lack of Apple hardware in the GNU ranks? ICYI, here's a URL for the discussion: '​https://savannah.gnu.org/bugs/?68223'

[pierow2k]

The article, from Apple, that I linked in my response tells you what is covered by System Integrity Protection.

Applications cannot arbitrarily disable SIP on macOS because doing so would undermine the very security boundary SIP is designed to enforce. SIP exists to prevent software, including privileged processes, from modifying, protected parts of the operating system or weakening core security protections without deliberate user action outside the normal runtime environment.

If an application could simply turn SIP off for itself, malware or untrusted software could do the same, making the protection meaningless. Requiring SIP changes to be performed manually through Apple-controlled recovery mechanisms helps ensure that disabling it is a conscious, high-friction decision by the user, not something software can silently do behind the scenes.

Here is that link again: ​https://support.apple.com/en-us/102149

System Integrity Protection includes protection for these parts of the system:

• /System
• /usr
• /bin
• /sbin
• /var
• Apps that are pre-installed with the Mac operating system

[seamusdemora (Seamus)]

@pierow2k:

I didn't say that 'findutils' must disable SIP! To repeat what I did say: "... instead of just failing completely to update the database, the port code should offer something besides complete and silent failure."

How you divined from that comment that I was suggesting SIP be disabled by 'findutils' - escapes me completely...

You copied a list that Apple provided. That's great, but it still doesn't explain what's broken - or how to fix it exactly. You suggest the --prunepaths option for /Volume, /System, /Library ... but in Terminal I can list MANY files that are in those folders. So why can't 'findutils' get at them in a read-only fashion? Apparently SIP doesn't prevent one from seeing all these files - does it?

[pierow2k]

I was not saying that you explicitly asked for findutils to disable SIP. I interpreted your comment that the issue "should be addressed in the code for the port" as suggesting that the port should somehow overcome a SIP-related restriction in code, and I replied to that interpretation. I understand now that your point was instead about the silent failure. I quoted Apple’s list in response to your statement that "AFAIK, Apple certainly doesn't provide this data!"

At this point, I have nothing further to add. I’ll leave it to the MacPorts team or others more familiar with this port’s behavior on macOS 13.7.7.

[seamusdemora (Seamus)]

I just realized the problem reported here has been around for a while. I also submitted ticket #65399 4-some years ago!

In the FWIW column: There has been some recent email on GNU's findutils mail list that covers (apparently) the same issue I've reported here. However, I don't see much resembling progress toward a fix - one of the problems seems to be that GNU's primary maintainer (Bernhard Voelker) says he doesn't own a Mac :[

[seamusdemora (Seamus)]

The issues certainly seem to be piling up with findutils: ​https://cgit.git.savannah.gnu.org/cgit/findutils.git/commit/?id=722c98ed390f

Perhaps MacPorts should just remove findutils from its repository??

[ryandesign (Ryan Carsten Schmidt)]

Replying to seamusdemora:

The issues certainly seem to be piling up with findutils: ​https://cgit.git.savannah.gnu.org/cgit/findutils.git/commit/?id=722c98ed390f

While that commit does seems to talk about a bug, and that the commit fixed it, I'm not sure how it relates to this MacPorts ticket. Nearly all software has bugs that get fixed.

Perhaps MacPorts should just remove findutils from its repository??

Removing findutils would break the two ports that depend on it:

% port echo depends:':findutils\y'
octave                          
gutils-suite-core               

According to the port's description, "findutils contains GNU find, xargs, and locate". While it's unlikely any port requires locate, octave might require find or xargs.

[seamusdemora (Seamus)]

Yeah... I agree... Probably a stupid comment, but I feel like I've been talking to myself on this ticket :)

Maybe we should just close/delete this ticket? It's not made a difference, and seems unlikely to do so in the immediate future. The issues all seem to be in the database and/or locate - they are completely dysfunctional AFAIK. But both find and xargs seem to work OK.

I'll leave that up to you - I'm OK either way.

[ryandesign (Ryan Carsten Schmidt)]

If updatedb and locate can't be fixed to work as well as the preinstalled updatedb and locate, maybe removing updatedb and locate from the findutils port is the solution, to avoid giving the impression that they work.

The maintainer of the port, to whom this ticket is assigned, hasn't been very active here lately, which is probably why you haven't gotten a response.

[seamusdemora (Seamus)]

Ryan,

If you can remove updatedb and locate, that may be a good solution. However, I'd recommend that you check with others (or yourself), and verify that is the case. I've tried this on two different late-model MacBook Pros (a 2023 model, and a 2026 model), and two different macOS versions: Tahoe and Ventura. It consistently fails on those. The fact that no one else has complained about this does cause me to wonder though...

~S

[tomio-arisaka (Tomio Arisaka)]

gupdatedb is a shell script. So we can see how it works. For example, on macOS High Sierra, I tried to build the glocate databases with gfind and gfrcode as follows:

(note: glocate allows us to use multiple databases)

$ sudo gfind /opt/X11 -type f -print0 | /opt/local/libexec/gfrcode -0 > ${HOME}/locatedb2
$ 
$ sudo gfind /opt \( -path "/opt/X11" -prune \) -o -type f -print0 | /opt/local/libexec/gfrcode -0 > ${HOME}/locatedb1
$ 
$ export LOCATE_PATH=${HOME}/locatedb1
$ 
$ glocate xload 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/x11/xload/Portfile
$ 
$ export LOCATE_PATH=${HOME}/locatedb1:${HOME}/locatedb2
$ 
$ glocate xload 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/x11/xload/Portfile
/opt/X11/bin/xload
/opt/X11/share/man/man1/xload.1
$ 

Another example, I tried to build a database used by glocate on ARM64 macOS Sonoma:

$ sudo gfind /System -type f -print0 | /opt/local/libexec/gfrcode -0 > ${HOME}/locatedb02
Password:
gfind: ‘/System/Volumes/Update/.TemporaryItems’: Operation not permitted
gfind: ‘/System/Volumes/Preboot/.TemporaryItems’: Operation not permitted
gfind: ‘/System/Volumes/Preboot/com.apple.security.cryptexd’: Operation not permitted
gfind: ‘/System/Volumes/xarts/.Trashes’: Operation not permitted
gfind: ‘/System/Volumes/Data/home’: Operation not permitted
gfind: ‘/System/Volumes/Data/.Spotlight-V100’: Operation not permitted
gfind: ‘/System/Volumes/Data/Library/Application Support/com.apple.TCC’: Operation not permitted
gfind: ‘/System/Volumes/Data/Library/Trial’: Operation not permitted
gfind: ‘/System/Volumes/Data/Library/Caches/com.apple.amsengagementd.classicdatavault’: Operation not permitted
gfind: ‘/System/Volumes/Data/Library/Caches/com.apple.aneuserd’: Operation not permitted
gfind: ‘/System/Volumes/Data/Library/Caches/com.apple.aned’: Operation not permitted
gfind: failed to read file names from file system at or below ‘/System’: No such file or directory
$ 

So I changed the command in order to avoid the errors:

$ sudo gfind /System \( -path "/System/Volumes" -prune \) -o -type f -print0 | /opt/local/libexec/gfrcode -0 > ${HOME}/locatedb02
Password:
$ 

By the way, macOS file system supports extended attributes, file flags, and the Access Control Lists (ACL). /usr/bin/find can look for them, and /bin/ls can display them, if present.

For example, on ARM64 macOS Sonoma, extended attributes and file flags are used for System Integrity Protection (SIP):

$ /bin/ls -l@a /
total 11
drwxr-xr-x  22 root  wheel   704  3 10 18:56 .
drwxr-xr-x  22 root  wheel   704  3 10 18:56 ..
lrwxr-xr-x   1 root  admin    36  3 10 18:56 .VolumeIcon.icns -> System/Volumes/Data/.VolumeIcon.icns
----------   1 root  admin     0  3 10 18:56 .file
drwxr-xr-x   2 root  wheel    64  3 10 18:56 .nofollow
drwxr-xr-x   2 root  wheel    64  3 10 18:56 .resolve
drwxr-xr-x   2 root  wheel    64  3 10 18:56 .vol
drwxrwxr-x  13 root  admin   416  4 26 02:20 Applications
drwxr-xr-x  67 root  wheel  2144  4 26 02:20 Library
drwxr-xr-x@ 10 root  wheel   320  3 10 18:56 System
	com.apple.rootless	   0 
drwxr-xr-x   5 root  admin   160  4 26 02:20 Users
drwxr-xr-x  10 root  wheel   320  5  2 22:21 Volumes
drwxr-xr-x@ 39 root  wheel  1248  3 10 18:56 bin
	com.apple.rootless	   0 
drwxr-xr-x   2 root  wheel    64 11  7  2020 cores
dr-xr-xr-x   4 root  wheel  5244  5  2 21:41 dev
lrwxr-xr-x@  1 root  wheel    11  3 10 18:56 etc -> private/etc
	com.apple.rootless	   0 
lrwxr-xr-x   1 root  wheel    25  5  2 21:42 home -> /System/Volumes/Data/home
drwxr-xr-x   4 root  wheel   128 10 25  2023 opt
drwxr-xr-x   6 root  wheel   192  5  2 21:41 private
drwxr-xr-x@ 64 root  wheel  2048  3 10 18:56 sbin
	com.apple.rootless	   0 
lrwxr-xr-x@  1 root  wheel    11  3 10 18:56 tmp -> private/tmp
	com.apple.rootless	   0 
drwxr-xr-x@ 11 root  wheel   352  3 10 18:56 usr
	com.apple.rootless	   0 
lrwxr-xr-x@  1 root  wheel    11  3 10 18:56 var -> private/var
	com.apple.rootless	   0 
$ 
$ /bin/ls -lOa /
total 11
drwxr-xr-x  22 root  wheel  sunlnk             704  3 10 18:56 .
drwxr-xr-x  22 root  wheel  sunlnk             704  3 10 18:56 ..
lrwxr-xr-x   1 root  admin  -                   36  3 10 18:56 .VolumeIcon.icns -> System/Volumes/Data/.VolumeIcon.icns
----------   1 root  admin  -                    0  3 10 18:56 .file
drwxr-xr-x   2 root  wheel  -                   64  3 10 18:56 .nofollow
drwxr-xr-x   2 root  wheel  -                   64  3 10 18:56 .resolve
drwxr-xr-x   2 root  wheel  hidden              64  3 10 18:56 .vol
drwxrwxr-x  13 root  admin  sunlnk             416  4 26 02:20 Applications
drwxr-xr-x  67 root  wheel  sunlnk            2144  4 26 02:20 Library
drwxr-xr-x@ 10 root  wheel  restricted         320  3 10 18:56 System
drwxr-xr-x   5 root  admin  sunlnk             160  4 26 02:20 Users
drwxr-xr-x  10 root  wheel  hidden             320  5  2 22:21 Volumes
drwxr-xr-x@ 39 root  wheel  restricted,hidden 1248  3 10 18:56 bin
drwxr-xr-x   2 root  wheel  hidden              64 11  7  2020 cores
dr-xr-xr-x   4 root  wheel  hidden            5244  5  2 21:41 dev
lrwxr-xr-x@  1 root  wheel  restricted,hidden   11  3 10 18:56 etc -> private/etc
lrwxr-xr-x   1 root  wheel  hidden              25  5  2 21:42 home -> /System/Volumes/Data/home
drwxr-xr-x   4 root  wheel  hidden             128 10 25  2023 opt
drwxr-xr-x   6 root  wheel  sunlnk,hidden      192  5  2 21:41 private
drwxr-xr-x@ 64 root  wheel  restricted,hidden 2048  3 10 18:56 sbin
lrwxr-xr-x@  1 root  wheel  restricted,hidden   11  3 10 18:56 tmp -> private/tmp
drwxr-xr-x@ 11 root  wheel  restricted,hidden  352  3 10 18:56 usr
lrwxr-xr-x@  1 root  wheel  restricted,hidden   11  3 10 18:56 var -> private/var
$ 

ACLs and extended attributes are used for the Time Machine and the user accounts:

$ /bin/ls -led /Volumes/TM-22
drwxrwxr-x@ 6 maxima  staff  192  5  2 00:31 /Volumes/TM-22
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
$ 
$ /bin/ls -l@d /Volumes/TM-22
drwxrwxr-x@ 6 maxima  staff  192  5  2 21:42 /Volumes/TM-22
	com.apple.backupd.BackupMachineAddress	 -1 
	com.apple.backupd.ComputerName	 -1 
	com.apple.backupd.HostUUID	 -1 
	com.apple.backupd.ModelID	 -1 
	com.apple.macl	 -1 
	com.apple.timemachine.private.structure.metadata	 -1 
$ 

[ryandesign (Ryan Carsten Schmidt)]

Replying to seamusdemora:

Ryan,

If you can remove updatedb and locate, that may be a good solution. However,

Just to clarify, I'm just making suggestions; I personally am not currently working on changing this port.

Replying to tomio-arisaka:

gupdatedb is a shell script. So we can see how it works.

So I changed the command in order to avoid the errors:

$ sudo gfind /System \( -path "/System/Volumes" -prune \) -o -type f -print0 | /opt/local/libexec/gfrcode -0 > ${HOME}/locatedb02
Password:
$ 

Are you suggesting that gupdatedb should be changed in this way? If so, please propose it to the developers of findutils so that they can evaluate whether it is a suitable fix for inclusion in their software. If they say it is, then we can add a patch the port until they release a new version containing that fix.

By the way, macOS file system supports extended attributes, file flags, and the Access Control Lists (ACL). /usr/bin/find can look for them, and /bin/ls can display them, if present.

For example, on ARM64 macOS Sonoma, extended attributes and file flags are used for System Integrity Protection (SIP):

Or are you suggesting that gupdatedb should be changed in a different way that uses extended attributes and file flags to locate the paths that should be excluded?

[seamusdemora (Seamus)]

Replying to ryandesign:

Replying to seamusdemora:

Ryan,

If you can remove updatedb and locate, that may be a good solution. However,

Just to clarify, I'm just making suggestions; I personally am not currently working on changing this port.

Ryan, Just out of curiosity - as I'm not familiar at all with MacPorts charter/policy/management, etc:

Does MacPorts undertake modifications to its library of ported software (like findutils) that may not be compatible with macOS/Darwin? Or, is its role to provide feedback to the developers of these ports, leaving it to them to make the changes?

[seamusdemora (Seamus)]

Replying to ryandesign: Replying to tomio-arisaka:

gupdatedb is a shell script. So we can see how it works.

So I changed the command in order to avoid the errors:

$ sudo gfind /System \( -path "/System/Volumes" -prune \) -o -type f -print0 | /opt/local/libexec/gfrcode -0 > ${HOME}/locatedb02
Password:
$ 

Are you suggesting that gupdatedb should be changed in this way? If so, please propose it to the developers of findutils so that they can evaluate whether it is a suitable fix for inclusion in their software. If they say it is, then we can add a patch the port until they release a new version containing that fix.

By the way, macOS file system supports extended attributes, file flags, and the Access Control Lists (ACL). /usr/bin/find can look for them, and /bin/ls can display them, if present.

For example, on ARM64 macOS Sonoma, extended attributes and file flags are used for System Integrity Protection (SIP):

Or are you suggesting that gupdatedb should be changed in a different way that uses extended attributes and file flags to locate the paths that should be excluded?

If anyone is interested in reaching the developers, they're available on GNU's 'findutils' mail list. ICYI, here's a URL for a recent discussion on that list that may be related to this ticket: '​​https://savannah.gnu.org/bugs/?68223'

[seamusdemora (Seamus)]

I'm going to add the results of a little experiment I did:

OS version: macOS Mojave, v 10.14.6

MacPorts version: MacPorts base version 2.12.5 installed

findutils version: 4.10.0_0

$ touch ~/Rw9Qt57_gcA.random

$ sudo gupdatedb
gfind: '/private/var/db/fpsd/dvp': Operation not permitted
gfind: '/private/var/db/ConfigurationProfiles/Store': Operation not permitted
gfind: '/private/var/folders/zy/7_10l4d97996yps2jyddd5rr0000gq/0/com.apple.LaunchServices.dv': Operation not permitted
...
gfind: '/private/var/folders/8_/myc8fnc57pxbzsjh2zq6zw6c0000gn/0/com.apple.progressd/ClassKit': Operation not permitted
...
gfind: '/private/var/folders/zz/zyxvpxvq6csfxvn_n00000z000007r/0/com.apple.routined/dv': Operation not permitted 

$ glocate Rw9Qt57_gcA.random
/Users/seamus/Rw9Qt57_gcA.random

$ mv ~/Rw9Qt57_gcA.random ~/XvW92T0-y7h.modnar

$ sudo gupdatedb --prunepaths='/private/var'

$ glocate XvW92T0-y7h.modnar
/Users/seamus/XvW92T0-y7h.modnar

RESULT: On Mojave, using above-named MacPorts and findutils versions, gupdatedb appears to have built a functional locatedb file with - or without - the use of the --prunepaths option.

---

On a different Mac:

OS version: macOS Tahoe, v 26.4.1

MacPorts version: MacPorts base version 2.12.5 installed,

findutils version: 4.10.0_0

$ touch ~/Rw9Qt57_gcA.random

$ sudo gupdatedb
gfind: '/Library/Caches/com.apple.amsengagementd.classicdatavault': Operation not permitted
gfind: '/Library/Caches/com.apple.aneuserd': Operation not permitted
gfind: '/Library/Caches/com.apple.aned': Operation not permitted
gfind: '/System/Library/AssetsV2/com_apple_MobileAsset_UAF_FM_Visual': Operation not permitted
...
gfind: '/System/Volumes/Data/Library/Caches/com.apple.amsengagementd.classicdatavault': Operation not permitted
gfind: '/System/Volumes/Data/Library/Caches/com.apple.aneuserd': Operation not permitted
gfind: '/System/Volumes/Data/Library/Caches/com.apple.aned': Operation not permitted
gfind: failed to read file names from file system at or below '/': No such file or directory

$ locate Rw9Qt57_gcA.random 

$
#  i.e. null output  =>  empty locatedb

RESULT: On Tahoe, using above-named MacPorts and findutils versions, gupdatedb appears to have FAILED to build a functional locatedb file.

[pierow2k]

ryandesign:

If updatedb and locate can't be fixed to work as well as the preinstalled updatedb and locate, maybe removing updatedb and locate from the findutils port is the solution, to avoid giving the impression that they work.

I use both updatedb and locate and would not be in favor of removing these from findutils port unless they were included in an alternative port - which would negate the point of removing them from findutils.

seamusdemora:

Maybe we should just close/delete this ticket?

Seems like a good next step.

[seamusdemora (Seamus)]

Replying to pierow2k:

I use both updatedb and locate and would not be in favor of removing these from findutils port unless they were included in an alternative port - which would negate the point of removing them from findutils.

seamusdemora:

Maybe we should just close/delete this ticket?

Seems like a good next step.

May I ask what version of the OS you're using it on? In my case, they still work on my Mojave system... an OS that was released 8 years ago. How would you feel about this if you were running a late-model OS - on which it failed miserably and inexplicably? But in general I agree that the package shoudn't be completely removed if it benefits anyone.

Perhaps what is needed is addition of a Note to the 'findutils' package - to the effect that "findutils is BFU on recent versions of the OS"? My suggestion to close the ticket reflected some frustration I felt over "the situation": No fix in sight, and Apple continues to pre-empt its customers as Admins in favor of their "we know what's best for you" approach to all things they do. Let me be clear: I do not feel that closing the ticket is the "best solution" to this issue. People need to know the situation, and if it were deleted, how long would it be before another was opened?

And that's my 2p worth...