find: Error Messages From find
12.1 Error Messages From 'find'
===============================
Most error messages produced by find are self-explanatory. Error
messages sometimes include a filename. When this happens, the filename
is quoted in order to prevent any unusual characters in the filename
making unwanted changes in the state of the terminal.
'invalid predicate `-foo''
This means that the 'find' command line included something that
started with a dash or other special character. The 'find' program
tried to interpret this as a test, action or option, but didn't
recognise it. If it was intended to be a test, check what was
specified against the documentation. If, on the other hand, the
string is the name of a file which has been expanded from a
wildcard (for example because you have a '*' on the command line),
consider using './*' or just '.' instead.
'unexpected extra predicate'
This usually happens if you have an extra bracket on the command
line (for example 'find . -print \)').
'Warning: filesystem /path/foo has recently been mounted'
'Warning: filesystem /path/foo has recently been unmounted'
These messages might appear when 'find' moves into a directory and
finds that the device number and inode are different from what it
expected them to be. If the directory 'find' has moved into is on
a network filesystem (NFS), it will not issue this message, because
'automount' frequently mounts new filesystems on directories as you
move into them (that is how it knows you want to use the
filesystem). So, if you do see this message, be wary - 'automount'
may not have been responsible. Consider the possibility that
someone else is manipulating the filesystem while 'find' is
running. Some people might do this in order to mislead 'find' or
persuade it to look at one set of files when it thought it was
looking at another set.
'/path/foo changed during execution of find (old device number 12345, new device number 6789, filesystem type is <whatever>) [ref XXX]'
This message is issued when 'find' moves into a directory and ends
up somewhere it didn't expect to be. This happens in one of two
circumstances. Firstly, this happens when 'automount' intervenes
on a system where 'find' doesn't know how to determine what the
current set of mounted filesystems is.
Secondly, this can happen when the device number of a directory
appears to change during a change of current directory, but 'find'
is moving up the filesystem hierarchy rather than down into it. In
order to prevent 'find' wandering off into some unexpected part of
the filesystem, we stop it at this point.
'Don't know how to use getmntent() to read `/etc/mtab'. This is a bug.'
This message is issued when a problem similar to the above occurs
on a system where 'find' doesn't know how to figure out the current
list of mount points. Ask for help on <bug-findutils@gnu.org>.
'/path/foo/bar changed during execution of find (old inode number 12345, new inode number 67893, filesystem type is <whatever>) [ref XXX]"),'
This message is issued when 'find' moves into a directory and
discovers that the inode number of that directory is different from
the inode number that it obtained when it examined the directory
previously. This usually means that while 'find' was deep in a
directory hierarchy doing a time consuming operation, somebody has
moved one of the parent directories to another location in the same
filesystem. This may or may not have been done maliciously. In
any case, 'find' stops at this point to avoid traversing parts of
the filesystem that it wasn't intended to. You can use 'ls -li' or
'find /path -inum 12345 -o -inum 67893' to find out more about what
has happened.
'sanity check of the fnmatch() library function failed.'
Please submit a bug report. You may well be asked questions about
your system, and if you compiled the 'findutils' code yourself, you
should keep your copy of the build tree around. The likely
explanation is that your system has a buggy implementation of
'fnmatch' that looks enough like the GNU version to fool
'configure', but which doesn't work properly.
'cannot fork'
This normally happens if you use the '-exec' action or something
similar ('-ok' and so forth) but the system has run out of free
process slots. This is either because the system is very busy and
the system has reached its maximum process limit, or because you
have a resource limit in place and you've reached it. Check the
system for runaway processes (with 'ps', if possible). Some
process slots are normally reserved for use by 'root'.
'some-program terminated by signal 99'
Some program which was launched with '-exec' or similar was killed
with a fatal signal. This is just an advisory message.
Info Catalog
find: Error Messages
find: Error Messages From xargs