This command in my .sh script is supposed to look in /home/backup/VBtest for .sql.gz files and remove any older than 5 days:

find /home/backup/VBtest/*.sql.gz -mtime +5 -exec rm {} \;

But it doesn't. It gives me no warnings, no errors, just a silent fail. I am running it on CentOS 6.6.

EDIT - after comment suggestions, I also tried this find '/home/backup/VBtest' -name '*.sql.gz' -mtime +5 rm {} \; and got find: paths must precede expression: rm. Also what is the argument for file creation time (as opposed to file modified time)?

  • 1
    What output do you get if you don't use -exec? Do you really mean to pass a literal list of file paths to find? Sep 4, 2015 at 9:12
  • What do you mean older? -mtime only check for modification time.
    – cuonglm
    Sep 4, 2015 at 9:14
  • 3
    That's not how you use find. It should be more like find /home/backup/VBtest' -name '*.sql.gz' ... (test before you put in the exec part). Sep 4, 2015 at 9:15
  • I don't use unix/linux very often, but when I do I get the command syntax wrong. I will try all your suggestions now.
    – leylandski
    Sep 4, 2015 at 9:17
  • 1
    You need the -exec between +5 and rm: find /home/backup/VBtest -name "*.sql.gz" -mtime +5 -exec rm {} \;
    – Lambert
    Sep 4, 2015 at 9:32

2 Answers 2


It should be more like:

find /home/backup/VBtest/  -name '*.sql.gz' -mtime +5 # -exec rm {} \;

(remove the # from the exec part if this gives the correct results) This will scan the whole directory tree.

/home/backup/VBtest/*.sql.gz by itself would get expanded by the shell (almost equivalent to the above find command with -maxdepth 1) as you can learn by doing

echo /home/backup/VBtest/*.sql.gz 

You can go down a pure-shell route if you want to. All posix shells can compare timestamps ( [ + either -nt for "newer than" or -ot for "older than") so you just need a reference timestamp and then filter the expanded glob by that:

touch /tmp/5dAgo --date '5 days ago'
trap 'rm -f /tmp/5dAgo' exit
for file in /home/backup/VBtest/*.sql.gz; do
   #remove the echo if this give the expected results
   [ "$file" -ot /tmp/5dAgo ] && echo rm "$file" 

From find's man page:

    Numeric arguments can be specified as

   +n     for greater than n,
   -n     for less than n,
    n     for exactly n.

  -mtime n
          File's data was last modified n*24 hours ago.  See the comments for 
          -atime to understand how rounding  affects  the  interpretation  of
          file  modification times.

   -atime n
          File was last accessed n*24 hours  ago.   When  find  figures  out  
          how  many 24-hour  periods  ago  the  file  was  last  accessed, any 
          fractional part is ignored, so to match -atime +1, a file has to have 
          been accessed at least two days ago.

So, -mtime +5 will find those files last modified more than 5*24h ago and -mtime -5 will find those files last modified less than 5*24h ago. It clearly tells that if you have modified the file/s your command will not remove those files. Also try modifying the command as:

find /home/backup/VBtest/ -maxdepth 1 -name "*.sql.gz" -mtime +5 -exec rm {} \;
  • 1
    Why not a -delete rather than -exec rm {} ?
    – Hennes
    Sep 4, 2015 at 9:42
  • 1
    This worked eventually, I was using -mtime when I should have used -ctime, as it looks another script modified the files every morning.
    – leylandski
    Sep 4, 2015 at 9:42
  • 1
    "I was using -mtime when I should have used -ctime"  Are you sure that was significant?  Unix (generally) doesn't keep track of file creation time.  "ctime" refers to change time.  This is almost the same as "mtime".  Writing to a file is both a modification and a change.  Renaming or chmod'ing a file are examples of changes that are not modifications. Sep 4, 2015 at 9:58
  • 1
    -delete is not a valid find primary
    – schily
    Sep 4, 2015 at 9:58
  • 1
    -delete is a valid find action In GNU find.  It is not defined in POSIX. Sep 4, 2015 at 10:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .