Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In one of our severs (IBM AIX), we have a file in path /data/1002/ which we were not able to remove or delete using the 'rm' command. The error message we got is "rm: S1208001.002: A file or directory in the path name does not exist."

With the "-f" option, no error message was displayed, but the file is still there.

This file has a '0' byte size and when i use the command "touch S120801.002", i see two files with the same file name in that directory.

The directory listing is as below:

$ ls -l total 56
-rwxrwxrwx    1 oracle   dba               0 Feb 09 11:57 S1208001.002 
drwxrwxrwx    4 nobody   dba           24576 Feb 09 13:36 backup

How do I remove this bogus fie?



after using the touch command, the directory listing is as below:

$ ls -l total 56
-rwxrwxrwx    1 oracle   dba               0 Feb 09 11:57 S1208001.002 
-rwxrwxrwx    1 oracle   dba           77790 Feb 09 14:30 S1208001.002
drwxrwxrwx    4 nobody   dba           24576 Feb 09 13:36 backup
share|improve this question
Have you tried removing the parent folder of this "bogus" file? – user3914 Feb 9 '11 at 5:51
Can you please provide full output, and fix the line breaks so that each line of ls -l appears on a separate line in your question? – Mikel Feb 9 '11 at 6:31
Your output says "S1208001.002" but you are asking about "A120001.002"? – Mikel Feb 9 '11 at 6:31
I'm assuming the touch command you used was "touch A1208001.002" and not "touch A120001.002" as currently listed in the question? – Robert Novak Feb 9 '11 at 6:32
sorry, typo on my post.. it's 'S120801.002' and not 'A120801.002' – Alvin Sim Feb 9 '11 at 9:18

It sounds like this filename may contain a non-printable character. That would explain "touch" making a different file.

Try something like

       ls -b

in the directory to see if that's the case?

Then you should be able to do something like:

       rm -i S*2 

and it should prompt you for the file even with the hidden character.

Alternately, you may be able to use find to do this...

       find . -name S\*2 -exec /bin/rm -i {} \;

should prompt you for the files... I don't know if AIX 'find' syntax is unusual so this might not work, but the 'rm -i' part should let you abort the command if it's wrong.

share|improve this answer
Your suggestions won't work if the non-printing character is at the beginning or end of the name. Your technique could be adapted to work in those cases, however. – Dennis Williamson Feb 9 '11 at 6:55
thanks.. the non-printable character was actually a blank space.. – Alvin Sim Feb 10 '11 at 5:45

You could try by inode. I am not sure what special char you've got going on there, but this might be worth a try:

$ touch badfile^M
$ ls -il bad*
   99 -rw-r--r--    1 username  group               0 Feb 09 04:39 badfile
$ find . -inum 99 -exec /bin/rm {} \;
$ ls -li bad*
ls: 0653-341 The file bad* does not exist.
share|improve this answer
On AIX with it's "different" flavor of find, looking up the file by inode and using find to exec an rm has worked quite successfully for us. – Corey S. Feb 9 '11 at 12:47

There's a space at the end of the file (or some other unprintable character). Try selecting both lines in your $ ls -l output to see it. To remove it, you could try the completely safe find method:


absolute_dir_path_x="$(readlink -fn -- "$dir"; echo x)"

while IFS= read -rd $'\0' path
    file_path="$(readlink -fn -- "$path"; echo x)"
    echo "START${file_path}END"
done < <( find "$absolute_dir_path" -type f -name '*S1208001*' -print0 )

Then you can probably just add a rm -- "${file_path}" at the end of the while loop.

share|improve this answer
Thanks, @l0b0.. you are right.. there was a space at the end of the file name which we didn't notice.. finally we managed to remove that file.. – Alvin Sim Feb 10 '11 at 5:44

Possible the Filesystem hold the file until the last process stops using it or until the fs cleans up.

I've seen something similar on NFS mounted NetApp-Shares. Just wait a little and the file disappears.

share|improve this answer

I've experienced a similar problem and a simple fsck (and then rm again) solved my issue

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.