GNU-Version von locate – gupdatedb schlägt mit „gfind: failed to read file names from file system“ fehl

Ich versuche, die GNU-Version des Befehls zu testen locate. Zuerst muss ich die Datenbank wie folgt erstellen:

sudo gupdatedb --prunepaths=/Volumes --output=$HOME/locatedb_gupdatedb

Leider erhalte ich 1 Minute nach dem Start des Befehls immer noch die folgende Fehlermeldung:

gfind: failed to read file names from file system at or below '/': No such file or directory

Ich verstehe nicht, woher dieser Fehler kommen könnte?

UPDATE 1: Ich habe es gfinddurch findein Komma und den korrekten Pfad ersetzt, finddessen /usr/bin/. Leider bekomme ich peinliche Fehlermeldungen wie diese, wenn ich den gupdatedbBefehl wie folgt starte:

sudo gupdatedb --prunepaths='/private/tmp /private/var/folders /private/var/tmp */Backups.backupdb /Volumes /System' --output=$HOME/locatedb_gupdatedb

Hier die Fehlermeldungen:

find: /System/Volumes/Data/.Spotlight-V100: No such file or directory
find: /System/Volumes/Data/.PKInstallSandboxManager: No such file or directory
find: /System/Volumes/Data/.PKInstallSandboxManager-SystemSoftware: No such file or directory
find: /System/Volumes/Data/.cleverfiles: No such file or directory
find: /System/Volumes/Data/mnt: No such file or directory
find: /System/Volumes/Data/.DocumentRevisions-V100: No such file or directory
etc ...

/usr/local/Cellar/findutils/4.7.0/libexec/bin/gupdatedbIch habe versucht , die Option in die Datei zu ändern :

: ${FINDOPTIONS="2 > /dev/null"}

Aber das Problem ist, dass diese Option vor dem Befehl gesetzt wird find, nicht am Ende, also ist sie im Folgenden der Datei nicht korrekt.

findAngesichts der Tatsache , dass das Skript viele Befehle enthält , kann ich die 2 > /dev/nullTerminaloption nicht jedes Mal manuell hinzufügen.

Jeder konnte sehen, wie man all diese Fehlermeldungen vom findBefehl unterdrückt, wenn ich einen gupdatedbBefehl starte?

UPDATE 2: Ich habe es endlich geschafft, eine Datenbank mit gupdatedb (GNU-Version des MacOS- updatedbBefehls) zu erstellen, indem ich Folgendes mache:

sudo gupdatedb --prunepaths='/private/tmp /private/var/folders /private/var/tmp */Backups.backupdb /System /Volumes' --output=$HOME/locatedb_gupdatedb

Das Problem ist jetzt, wenn ich eine Suche nach einer Teilzeichenfolge einer Datei oder eines Verzeichnisses durchführe, scheinen die Informationen in den Ergebnissen dupliziert zu werden ( sub_stringist einfach der Teil eines Datei- oder Verzeichnisnamens):

Wenn ich z.B. folgendes mache:glocate -d ~/locatedb_gupdatedb sub_string

Dann habe ich doppelte Ergebnisse wie:

/System/Volumes/Data/Users/fab/sub_string.dat
/Users/fab/sub_string.dat

Ich weiß nicht, wie ich ' /System/Volumes/Data/' aus diesen Ergebnissen ausschließen soll: Ich habe jedoch in --prunepathsder Option das Verzeichnis genau angegeben System, warum wird es in der von erstellten Datenbank nicht berücksichtigt gupdatedb?

Oder vielleicht sollte ich eine durchführen:

sudo gupdatedb --prunepaths='/private/tmp /private/var/folders /private/var/tmp */Backups.backupdb /System/Volumes/Data /Volumes' --output=$HOME/locatedb_gupdatedb

??

Jede Hilfe ist willkommen, um dieses Verzeichnis auszuschließen

/System/Volumes/Data

aus der Indizierungsdatenbank.

UPDATE 3: Hier ist ein Beispiel für die schnelle Generierung einer Datenbank mit updatedb on Debian 10 Buster. Zwischen den Zeitstempeln der beiden Befehle wurden einige Änderungen der normalen Verwendungupdatedb vorgenommen .

Daher schließe ich, dass es wirklich einen Unterschied zwischen der GNU/MacOS- und der GNU/Linux-Implementierung gibt.

Jede Erklärung ist willkommen.