14

I'm not even sure if this is easily possible, but I would like to list the files that were recently deleted from a directory, recursively if possible.

I'm looking for a solution that does not require the creation of a temporary file containing a snapshot of the original directory structure against which to compare, because write access might not always be available. Edit: If it's possible to achieve the same result by storing the snapshot in a shell variable instead of a file, that would solve my problem.

Something like:

find /some/directory -type f -mmin -10 -deletedFilesOnly

Edit: OS: I'm using Ubuntu 14.04 LTS, but the command(s) would most likely be running in a variety of Linux boxes or Docker containers, most or all of which should be using ext4, and to which I would most likely not have access to make modifications.

Marco Roy
  • 4,004
  • 7
  • 34
  • 50
  • 5
    Virtually impossible. Deleted files are *deleted* in Linux -- no built-in safety net. If you wanted to try something REALLY fancy, you could try this: http://unix.stackexchange.com/questions/80270/unix-linux-undelete-recover-deleted-files ...but for what you seem to need, that's probably overkill. – kittykittybangbang Aug 07 '15 at 17:56
  • only thing I can think of is IF the file was edited and a backup was kept from editing the file, search for any file in a directory that is such as `foo.bar~` but has no `foo.bar` in the directory thus **assuming** the file was deleted. – jgr208 Aug 07 '15 at 17:58
  • 2
    the answer depends on the file system used, not on the operation system itself. the only relation to `linux` is that what you are asking for is not possible for most popular linux file systems. – Alex P. Aug 07 '15 at 18:07
  • but with most file systems many have seen on linux using the CLI interface it is mostly impossible. So you may you tell us what Linux OS you are using? – jgr208 Aug 07 '15 at 18:09

5 Answers5

16

You can use the debugfs utility,

debugfs is a simple to use RAM-based file system specially designed for debugging purposes

First, run debugfs /dev/hda13 in your terminal (replacing /dev/hda13 with your own disk/partition).

(NOTE: You can find the name of your disk by running df / in the terminal).

Once in debug mode, you can use the command lsdel to list inodes corresponding with deleted files.

When files are removed in linux they are only un-linked but their inodes (addresses in the disk where the file is actually present) are not removed

To get paths of these deleted files you can use debugfs -R "ncheck 320236" replacing the number with your particular inode.

Inode   Pathname
320236  /path/to/file

From here you can also inspect the contents of deleted files with cat. (NOTE: You can also recover from here if necessary).

Great post about this here.

nextstep
  • 1,399
  • 3
  • 11
  • 26
  • 1
    `lsdel` shows you inodes that belonged to files that were deleted; is there anyway to see the *names* of the delete files? – chepner Aug 07 '15 at 20:12
  • I'm not sure if there's a way to output all the filenames, but you can retrieve the contents of a file with the `cat` command. Like this, `cat <32611>`, replacing the number with the inode you want to check. – nextstep Aug 07 '15 at 20:23
  • 1
    That just gives you the contents of an unknown set of files. The question asked for the identities of the deleted files, not their contents. – chepner Aug 07 '15 at 20:39
  • Edited to explain retrieving filenames of deleted files. – nextstep Aug 07 '15 at 21:11
  • unfortunately this did not work in my case. i have xfs on LVM – b10n1k Oct 13 '20 at 12:37
1

So a few things:

  1. You may have zero success if your partition is ext2; it works best with ext4

  2. df /

  3. Fill mount point with result from #2, in my case:

    sudo debugfs /dev/mapper/q4os--desktop--vg-root

  4. lsdel

  5. q (to exit out of debugfs)

  6. sudo debugfs -R 'ncheck 528754' /dev/sda2 2>/dev/null (replace number with one from step #4)

Display name
  • 1,228
  • 1
  • 18
  • 29
E L
  • 11
  • 1
  • Since you are formally posting an answer to an older question. It would be most helpful that you support your purported answer with some code and the output that results from using your code. Try copy and pasting some of the result or even a screen print that demonstrates you code. – Gray Sep 24 '20 at 20:55
0

Thanks for your comments & answers guys. debugfs seems like an interesting solution to the initial requirements, but it is a bit overkill for the simple & light solution I was looking for; if I'm understanding correctly, the kernel must be built with debugfs support and the target directory must be in a debugfs mount. Unfortunately, that won't really work for my use-case; I must be able to provide a solution for existing, "basic" kernels and directories.

As this seems virtually impossible to accomplish, I've been able to negotiate and relax the requirements down to listing the amount of files that were recently deleted from a directory, recursively if possible.

This is the solution I ended up implementing:

  1. A simple find command piped into wc to count the original number of files in the target directory (recursively). The result can then easily be stored in a shell or script variable, without requiring write access to the file system.

DEL_SCAN_ORIG_AMOUNT=$(find /some/directory -type f | wc -l)

  1. We can then run the same command again later to get the updated number of files.

DEL_SCAN_NEW_AMOUNT=$(find /some/directory -type f | wc -l)

  1. Then we can store the difference between the two in another variable and update the original amount.

DEL_SCAN_DEL_AMOUNT=$(($DEL_SCAN_ORIG_AMOUNT - $DEL_SCAN_NEW_AMOUNT)); DEL_SCAN_ORIG_AMOUNT=$DEL_SCAN_NEW_AMOUNT

  1. We can then print a simple message if the number of files went down.

if [ $DEL_SCAN_DEL_AMOUNT -gt 0 ]; then echo "$DEL_SCAN_DEL_AMOUNT deleted files"; fi;

  1. Return to step 2.

Unfortunately, this solution won't report anything if the same amount of files have been created and deleted during an interval, but that's not a huge issue for my use case.

To circumvent this, I'd have to store the actual list of files instead of the amount, but I haven't been able to make that work using shell variables. If anyone could figure that out, I'd help me immensely as it would meet the initial requirements!

I'd also like to know if anyone has comments on either of the two approaches.

Marco Roy
  • 4,004
  • 7
  • 34
  • 50
0

Try:

lsof -nP | grep -i deleted
Ryan M
  • 18,333
  • 31
  • 67
  • 74
Rupali Bajpai
  • 11
  • 1
    Sorry, that doesn't answer the original question. The `lsof` command just lists OPEN files; if the files were deleted, they are not going to be open currently. (There might be a tiny exception, if a process has a file open, another process deletes the file.) – Mark Stewart Oct 18 '21 at 19:12
-2

history >> history.txt

Look for all rm statements.

Surfer Buddha
  • 75
  • 7