Delete a corrupt file in Linux

Ok, so I have the same problem as stig and garlicman and none of what has been posted is the correct way to deal with this, which I've only just now figured out.

I couldn't do anything with the files, all I had was questions marks when doing ls -li. mv, rm and even ls gives an error:

ls: cannot access 'myfile.txt': Bad message

The real solution is to unmount the disk and run e2fsck on it, which will find the errors and ask if you want to fix them. For example:

sudo umount /dev/sd<whatever>
sudo e2fsck /dev/sd<whatever>

I then rebooted and everything is back to normal (rebooting previously did not fix the issue).

The corrupted file will be gone after a reboot.

BTW I tried many solutions running many commands on the terminal, but only the rebooting worked in my case.

A bit of explanation:

In my case, there was a log file that I deleted from my IDE, but it reappeared. I tried to do rm and similar tricks, but nothing worked. I ran ls -l and observed that the second column (hard link count to the file/directory) was zero.

-rwxrwxrwx 0 ashen ashen 457 May 23 21:30 app.log

Normally this number is >0 and when a link is removed, the value is decreased by one (rm command does this). According to Wikipedia,

"If the link count becomes zero, the operating system usually automatically deallocates the data space of the file if no process has the file opened for access, but it may choose not to do so immediately, either for performance or to enable the undelete command.

The maintenance of this value guarantees that there will be no dangling hard links pointing nowhere (which can and does happen with symbolic links) and that filesystem file and associated inode will be preserved as long as a single hard link (directory reference) points to it or any process keeps the associated file open, relieving the burden of this accounting from programmer or user. This is a simple method for the file system to track the use of a given area of storage, as zero values indicate free space and nonzero values indicate used space."

Therefore, my observation is that the OS needs a reboot for cleaning some of the corrupted files.

I'm not sure if any of the answers here have actually had the issue Stig reported. I just ran into this problem myself on my ext4 filesystem:

# ls -l /tmp/dependencies/
ls: cannot access /tmp/dependencies/easy-rsa-master: No such file or directory
total 0
?????????? ? ? ? ?            ? easy-rsa-master

# ls -i /tmp/dependencies/
ls: cannot access /tmp/dependencies/easy-rsa-master: No such file or directory
? easy-rsa-master

# rm -r /tmp/dependencies
rm: descend into directory ‘dependencies’? y
rm: cannot remove ‘/tmp/dependencies/easy-rsa-master’: No such file or directory
rm: remove directory ‘dependencies’? y
rm: cannot remove ‘dependencies’: Directory not empty

The file itself was corrupt along with its file attributes. ls -i clearly shows no inode ID. No usage of rm will do the trick. Even rm -rf traverses into the directory and tries to delete the file directly (and silently).

My solution was to recreate the directory without the offending file. Then you can move the directory to another location, like /tmp. It'll be gone after a reboot or whenever your distro cleans the /tmp directory (hopefully).

If you want to delete every corrupt files, you can do this:

ls -1 | grep -P "[x80-xFF]" | xargs rm

Above grep command grep files which has non ASCII characters.

One possibility is to find out the inode number of the file, which you can do by running ls -i. This will return two columns -- the first being the inode, and the second being the filename. You can then use the find command to select only the file with that specific inode, and delete it.

sh-4.1$ ls -i .
  17921 somefile.ods
    169 someotherfile.conf
    305 -????????? ? ? ? ? ? 100.jpg
  18048 yetanotherfile.jpg

sh-4.1$ find . -maxdepth 1 -inum 305 -ok rm '{}' ;
< rm ... -????????? ? ? ? ? ? 100.jpg > ? y

Since the inode is most likely unique to the file (assuming no hardlinks), this will allow you to delete without the risks inherent with wildcards. The maxdepth and the ok options of the find command just make it even less likely that you'll hit the wrong file by accident.

You can try this:

1. Rename your directory.
2. Recreate the original directory (empty).
3. Copy other files back to it.
4. Delete the directory containing that file.

I'd recommend a slightly more defensive version of cHao's suggestion:

rm -i ./*100.jpg*

The -i makes rm ask you whether or not to delete each file that matches the wildcard; this ensures that you won't accidentally delete other files as well. And the leading ./ ensures that all the filenames will be treated as filenames and not further options to rm (it looks like you might have a leading dash in there, is why this is important).

It's possible, by the way, that there are invisible characters inside the string "100.jpg". If the above gives you an error message like "rm: ./*100.jpg*: not found", that's why. ls -1fw | cat -v may be helpful.

You might try

rm *100.jpg*

The ?'s are either literal question marks or characters that don't make sense. Either way, the OS itself (and the shell) can usually remove the file, if the filesystem isn't hosed.

If the filesystem is messed up, though, deleting stuff may make it worse. I'd recommend you boot into Windows to scan the drive, and delete the file there if you can.