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?

Thanks.

UPDATE 1

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
link|improve this question

25% accept rate
Have you tried removing the parent folder of this "bogus" file? – Randolph West 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
show 1 more comment
feedback

5 Answers

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.

link|improve this answer
2  
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
1  
thanks.. the non-printable character was actually a blank space.. – Alvin Sim Feb 10 '11 at 5:45
feedback

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.
link|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
feedback

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:

dir=/path/to/your/directory

absolute_dir_path_x="$(readlink -fn -- "$dir"; echo x)"
absolute_dir_path="${absolute_dir_path_x%x}"

while IFS= read -rd $'\0' path
do
    file_path="$(readlink -fn -- "$path"; echo x)"
    file_path="${file_path%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.

link|improve this answer
1  
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
feedback

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.

link|improve this answer
feedback

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

link|improve this answer
feedback

Your Answer

 
or
required, but never shown

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