How to delete .fuse_hidden* files?

I have small Linux server (Debian Squeeze) which runs a Samba server which is configured to share some folders with some windows machines. While trying to delete one of the directories from windows I received the "Cannot delete folder" error.

I tried to delete the directory from the linux's console I got a similar error:

# rm dir-name -rf
rm: cannot remove `dir-name': Directory not empty

I listed the contents of the directory and found a file named .fuse_hidden followed by a hex number (000bd8c100000185).

# ls -la dir-name
-rwxrwxrwx 1 root root 5120 Feb 13 11:46 .fuse_hidden000bd8c100000185

I tried to delete the .fuse_hidden file, but a new file was created instantly (note the hex number change).

# rm dir-name/.fuse_hidden000bd8c100000185
# ls -la dir-name
-rwxrwxrwx 1 root root 5120 Feb 13 11:46 .fuse_hidden000bd8c100000186

I also tried using Midnight Commander to delete the file with no success.

Other solutions I have found so far involve GUI and I've only got console.

Any suggestions are appreciated.

Solution 1:

This is similar to what happens when you delete a file that another system has open on a NFS mount. The problem is that the file has been removed from the filesystem while its "link count" was >1, meaning that other processes are still holding it open.

• Log in to the system where the file physically resides. (no network mount)
• Execute lsof dir-name/.fuse_hidden000bd8c100000185 to find out what processes are holding the file handle open.
• Terminate those processes if it makes sense to, or figure out what steps you can perform to "gracefully" release the open file handle without terminating the process.

Normally, when you delete a file on your local filesystem that another process has open, the OS complies with your request and removes it from the directory tree, but the inode that tree points to is still considered in use by the operating system. Every time a file is opened, its "link count" increments by one, and the space is only truly released when that link count hits zero.

When you run into a problem of this nature, it means that the OS has for whatever reason decided to not remove that file from the directory tree: usually because it has reason to believe that it still needs to be accessed by things that can't utilize the direct inode number. It might initially seem to comply, but behind the scenes the OS renames it to have a hidden dot-prefix so that is still accessible with some form of filesystem path addressing. The space will still be freed when the link count hits zero, but that object will will remain in the directory until the links are gone.