As I pointed out in another thread: Problems like this can arise if the file system is running in a strange locale and/or the file names contain strange characters. This can lead to effects like multiple files with the same name in a directory , or files that are absolutely inaccessible. Supposedly it often helps to put all user processes involved into a utf8 locale, because then fewer character set conversions need to be done.
The idea of running "file" inside "find" to check whether a file is accessible is insane, because it might fail due to a myriad of other reasons. It is also unnecessary. You can easily do the equivalent thing in shell: take the output of "find", pipe it into a shell loop (to prevent names with embedded blanks from being broken apart by the shell, use "-print0" to print the file name in find), then in the shell loop check whether files exist or accessible (readable, executable) using the standardized test in if statements (do a "man test" to read about those). Since the file names (in the output of find) are null-terminated, it is possible to read them with trickery into shell variables (look at IFS= and the -d option of read) without any trimming of leading or trailing blanks, with blanks in the middle, and with international characters.
And if you find files that even these techniques don't work well on, then the right answer is to call the readdir() system call from a programming language, and process the output yourself, for example looking for special characters. This can be done quite easily in perl or python.
