I can think of two possibilities that would result in such error messages:

1) native XFS with file system damage; run xfs_check and xfs_repair.
(If this is on the root system, then this can get ``interesting.'')
2) Dangling sysmbolic links. rm should fix these.

(You have implied that these are native file systems and not NFS served
to this machine; otherwise, the same situation, but on the server.)

Randolph J. Herber, herber@fnal.gov, +1 630 840 2966, CD/CDFTF PK-149F,
Mail Stop 318, Fermilab, Kirk & Pine Rds., PO Box 500, Batavia, IL 60510-0500,
USA. (Speaking for myself and not for US, US DOE, FNAL nor URA.) (Product,
trade, or service marks herein belong to their respective owners.)

The following header lines retained to effect attribution:
|X-Trace:
|Date: Tue, 12 Aug 2003 16:00:08 -0400
|From: Kirt Dankmyer aka Loki
|Subject: directly modifying directory entries?
|To: info-iris-misc@ARL.ARMY.MIL

|Is there any way to directly modify a directory entry? On one of my
|Origin 200 boxes I have some files in the /tmp directory that show up
|in the directory listing but "don't exist" so I can't delete them.

|It's like this:

|mybox # cd tmp
|mybox # ls
|cr33p cr4p espdb.sock grio.lock
|mybox # rm -f cr*
|Cannot access ./cr33p: No such file or directory
|Cannot access ./cr4p: No such file or directory
|mybox # ls -l
|Cannot access ./cr33p: No such file or directory
|Cannot access ./cr4p: No such file or directory
|Srwx------ 1 root sys 0 Jun 2 17:37 espdb.sock
|-rw-r--r-- 1 root sys 4 Jun 2 17:37 grio.lock
|mybox # unlink cr33p
|Cannot access ./cr33p: No such file or directory
|maybox # ls
|cr33p cr4p espdb.sock grio.lock
|mybox #

|Obviously those aren't the actual file names but you get the picture.
|Any way to get rid of these "files"? This is on an XFS filesystem, if
|that makes a difference.