Alright, I've been searching the forum all afternoon and I cannot find clues to help me resolve my problem....

I have a file showing up when I do ls -a | grep file_name but when I try to delete the file it tells me the file doesn't exist.

If I just do an ls file_name it tells me the file does NOT exist.

Based on ls -al I DO have owner and group permissions of the file. The files permission level is 664.

And when I do an ls -i file_name it DOES return an inode number.

If I dismount the drive and FORCE an e2fsck, it checks my entire disk and finds no errors.

If I try to force: rm -f file_name, it silently returns like it was deleted but ls -a | grep file_name still shows the file_name. Again, permissions are 664 with me as the owner & group. I get the same results when I do these same steps as root.

How can I delete this file that appears to have a valid inode but I can't see with a standard ls command?

hello to remove the file
"rm -rf filename"

hi!,

No, that does not work. The file remains.

r u in the same directory as the file when u type the command

I've tried it both ways: being in the same directory and not being in the same directory and typing the full path to file_name

First use auto completion when trying to delete the file. Sometimes a file has some tricky characters that can fool you. Also, do you have write access permission on the files directory. Deleting a file is actually writing to the directory file, so you need write access on the directory itself.
Second, if the file is on an ext2 filesystem, it may have extended attributes. Use lsattr to find out if the 'immutable' attributes is set. The XFS file system has name:value pair extended attributes. Also, if you are using an SLE kernel. All files and processes have attribute pairs which control access.

If the sticky bit is set in on the containing directory, then only the owners can delete files.

One other thing with Linux and Unix that surprised me when I found out about it, is if the permission bits deny access to the owner, then the owner is denied access even if the owner has group permission. The same is true if the group permissions deny access to a group member, even if the other permissions would allow it.
This isn't the problem in your case because the permission bits allow it.

If another process or user has a lock on the file, you won't be able to delete it.
You can check this out with lsof <filename> | grep "<filename>" | grep -v grep

One other thing to check is if the file has a link referencing it. Look in the second column of the ls -l listing. If the second column is greater than 1 then that is the case.
Lastly, try deleting it using a file browser. The browser may reference the file by inode entry rather than by name.

doh!! Completely forgot about that.... that did the trick... the tab completion showed the file had hidden spaces at the end of file_name which were preventing me from manipulating it properly.

Thank you!!