2

I accidentally started an rm -rf on a large directory that I was working in. The directory contains, among other things, a data directory containing a number of subdirectories that each contain thousands of text files. Essentially it looks like this

$ tree data data ├── collection0 │ ├── input │ │ ├── file0.txt │ │ ├── file1.txt │ │ ├── ... │ │ └── file9999.txt │ └── output │ ├── file0.txt │ ├── file1.txt │ ├── ... │ └── file9999.txt ├── ... └── collection99 ├── input │ ├── file0.txt │ ├── file1.txt │ ├── ... │ └── file9999.txt └── output ├── file0.txt ├── file1.txt ├── ... └── file9999.txt

I was able to interrupt the rm -rf process pretty quickly, but of course in the half-second or so of execution time a number of files in other subdirectories were deleted.

My question is, is there a way to ascertain with 100% certainty whether a given subdirectory lost any files during this time? It seems as though the Modify time on directories that lost files got updated to when the files were deleted, and using this method I think no files in the data subdirectories was deleted (assume 2021-09-08 is the date of the rm -rf event):

$ find data -mindepth 2 -maxdepth 2 -type d -exec stat {} -c '%n %y' \; data/collection0/input 2021-08-28 05:45:49.624228368 -0400 data/collection0/output 2021-08-28 05:45:49.624228368 -0400 ... data/collection99/input 2021-08-29 04:55:38.772912003 -0400 data/collection99/output 2021-08-29 04:55:38.772912003 -0400 $ find data -mindepth 2 -maxdepth 2 -type d -exec stat {} -c '%n %y' \; | grep 2021-09-08 $

Is this a reliable method?

Improve this question

1 Answer 1

Reset to default
1

The Linux man page for stat(2) says that:

The field st_mtime is changed by file modifications, for example, by mknod(2), truncate(2), utime(2), and write(2) (of more than zero bytes). Moreover, st_mtime of a directory is changed by the creation or deletion of files in that directory. The st_mtime field is not changed for changes in owner, group, hard link count, or mode.

The field st_ctime is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.).

So, yes, should be able to rely on the modification time being updated if the rm touched each directory. Provided of course that it wasn't manually reset afterwards, but in that case, the change timestamp (ctime) should be updated. Well, if I understand the man page text correctly, the ctime also updates any time mtime does, so it should be enough to look at just that one.

Also, you can only use mtime to prove the negative. If the timestamp is updated, there's no way to know if it happened due to a file being removed, or another being created, or the timestamp being manually modified.

Improve this answer
2
  • Thanks. All I needed in this case was to prove was the negative, as there were no other modifications done. Does it seem to you like there probably isn't a way to prove the positive ex post facto? Commented Sep 8, 2021 at 21:38
  • 1
    @AngusL'Herrou, in practice you could probably assume that if the timestamp changed at the same time as rm was running, then it's probably due to it. Especially if you know there aren't any other users or programs touching those files. But in principle it might have been something else and the system doesn't really keep logs of what happened. (except for the internals of some log-based or copy-on-write filesystems might, but it's harder to get to those) Commented Sep 8, 2021 at 21:42

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.