0

I want to delete the specific file, std_info under /tmp, if it hasn't been modified within a day (or 1440 minutes).

For now, I created the following syntax that prints only the files that were modified within one day:

 find /tmp -mmin -1440 -type f -exec ls -l {} +

but how to do the opposite way?

In order to removed the std_info file under /tmp that wasn't modified within 1 day?

Kusalananda
  • 333,661
yael
  • 13,106

1 Answers1

2
find /tmp/std_info -mmin +1440 -delete

Assuming that /tmp/std_info is a file, this would examine that file, and if it was modified more than 1440 minutes ago it would be deleted. Use -exec rm {} \; in place of -delete if your find does not have -delete.

If the file might not exist, use

[ -e /tmp/std_info ] && find /tmp/std_info -mmin +1440 -delete

To delete any file named std_info under /tmp that was modified more than 1440 minutes ago, use

find /tmp ! -type d -name std_info -mmin +1440 -delete

I'm using ! -type d to also include symbolic links and other type of files other than directories.

Kusalananda
  • 333,661
  • better to do find /tmp -name std_info -mmin +1440 -delete – yael Jan 05 '20 at 11:45
  • @yael Why? If you use that, you would also have to guard against matching other files with the same name in subdirectories! It would also needlessly go through and test every other file under that hierarchy. You are just interested in a single file, so it makes no sense to look at other files. – Kusalananda Jan 05 '20 at 11:46
  • because if file not exsist then you will get find: ‘/tmp/xxxxx No such file or directory – yael Jan 05 '20 at 11:48
  • @yael You specified that you had a file that you wanted to check. This implies that the file exists. If it might not exist, then it would be more efficient to use [ -e /tmp/std_info ] && find /tmp/std_info -mmin +1440 -delete than to search through a whole directory structure for a file that does not exist. – Kusalananda Jan 05 '20 at 11:50
  • I give it like example , it could be under /tmp/folder1/folder2/... , sorry if my question was not clearly – yael Jan 05 '20 at 11:52
  • @yael Then it's not very specific. If you mean "any file named std_info", then don't say "a specific file named std_info". – Kusalananda Jan 05 '20 at 11:54
  • I means this specific files but this file could be under /tmp in any sub folder or subs folders as ( /tmp/folder1/folder2/folder299/std_info – yael Jan 05 '20 at 11:57
  • ( +1 for your effort - you deserve it ) – yael Jan 05 '20 at 12:03
  • can we replace the flag - -mmin with other flag that will be in days? – yael Jan 05 '20 at 12:39
  • @yael The -mtime test will test modification time in days, so -mtime +1 will match something that was modified more than 1 days ago (i.e. 2 day ago or more). See also https://unix.stackexchange.com/questions/92346/why-does-find-mtime-1-only-return-files-older-than-2-days – Kusalananda Jan 05 '20 at 12:41
  • @StéphaneChazelas A slightly older find on OpenBSD won't have it while still supporting -mmin, so I thought I'd play it safe. Isn't +1140 "more than 1440 minutes" ("1441 minutes or more")? – Kusalananda Jan 05 '20 at 15:25
  • -mmin +1440 won't match a file that is 1440.99999999 minutes old. Here, you want -mtime +0, or -mtime +1d with FreeBSD or ! -newermt '1 day ago' with GNU find at least. – Stéphane Chazelas Jan 05 '20 at 15:37
  • @StéphaneChazelas +1440 is from the user. BTW, I just submitted a bug report against OpenBSD's find. It does the wrong thing with -mtime +N (it does mtime >= N, not mtime > N). No wonder this has been confusing me in the past! – Kusalananda Jan 05 '20 at 15:54
  • It's all very confusing and unintuitive. Even the POSIX spec examples or the GNU find documentation examples get it wrong. Note that it's not limited to -xtime. -size works in a similar way. – Stéphane Chazelas Jan 05 '20 at 16:01
  • Looks like the problem is not limited to OpenBSD. FreeBSD and NetBSD have the same problem AFAICT. It seems it was introduced when the V7 code was replaced with a different implementation for BSD 4.3 Net/2 – Stéphane Chazelas Jan 05 '20 at 16:38
  • @StéphaneChazelas Yes. Ingo Schwarze just picked up my report and said the same. He might bring it to the Austin list. If he doesn't, then you may want to possibly do that to get the POSIX text corrected? I'm on the list, but don't know the formalities. As for the BSD implementation, fixing it is likely to break a number of scripts, so I don't have too high hopes for that at the moment. – Kusalananda Jan 05 '20 at 16:49
  • I don't expect POSIX will be willing to change it, it's been like that since forever, BSDs were compliant at the time POSIX was written. It's more of a regression in BSDs – Stéphane Chazelas Jan 05 '20 at 16:55
  • @StéphaneChazelas I was referring to the contradiction in the EXAMPLES section where it says "have not been accessed for seven or more 24-hour periods." about -atime +7. I definitely think +N should mean "strictly more than N". – Kusalananda Jan 05 '20 at 16:57
  • 1
    There's no formality, you can just send an email to the austin-group list if you want to start an informal discussion there. – Stéphane Chazelas Jan 05 '20 at 16:58
  • 1
    Are you refering to http://austingroupbugs.net/view.php?id=1259 – Stéphane Chazelas Jan 05 '20 at 16:59
  • @StéphaneChazelas Thanks for that. I'll point Ingo to it too. – Kusalananda Jan 05 '20 at 17:01