0

While cleaning up a portable HD I came across a directory that I cannot delete with the error that it is not empty, and that despite trying to delete it with the -rf flags (I am running linux).

I went in the directory and found 3 hidden files titled:

.fuse_hidden00000e6f0000002f
.fuse_hidden00000e8500000030
.fuse_hidden00000eb200000031

And upon deleting them they were instantly recreated, exactly the same by their checksums only with slightly different names (the last 2 characters advanced by 1 in hex).

Opening them with a hex editor I found mostly gibberish and some readable strings of files that might have been in the same directory before.

I tried to put a watch on that directory with auditctl but in the logs I only see my command for deleting them, but not the one recreating the new ones.

Any ideas on how to continue from here? Mainly on how to find which process is recreating them?

Tom Klino
  • 178
  • 1
  • 1
  • 5
  • Related: https://askubuntu.com/questions/493198/what-is-a-fuse-hidden-file-and-why-do-they-exist https://serverfault.com/questions/478558/how-to-delete-fuse-hidden-files – Alexander O'Mara Oct 07 '16 at 18:17

1 Answers1

1

.fuse_hiddenXXXX files are explained here on askubuntu.com

You can safely ignore .fuse_hiddenXXXX files. It means a file was deleted but there is at least one software which is still using it, so it can't be removed permanently.

It will be done automatically when the relevant software stops using the file or exists. Such files are always gone after umount/reboot. This is how Linux and any Unix works but only FUSE exposes these files to the user.

These files are also related to the ntfs-3g file system.

You can find out what application has the file open by using the lsof command.

lsof /full/path/name

-OR-

lsof /relative/directory/path/name

Community
  • 1
Matt Butler
  • 263
  • 1
  • 5
  • That's good to know about specifically the .fuse_hiddenXXX files. But I would like to refer to something more general as a way to find out what process is creating files in a certain directory. `lsof` is not good enough since files closed within 1 ms cannot be detected using it. I'm curious to know why watching a direcotry with `auditd` did not show me the process creating the files in this scenario. (BTW, this was a helpful answer, thanks.) – Tom Klino Oct 07 '16 at 20:03