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.