Hi !


I have inherited a system (macosx 10.4.3) where there is a directory
that has lots of temp files being deposited daily.

I do not want to delete all of these temp files, but I do want to prune
them daily.

What command line should I run to "find" all files that are over 3 days
old and delete them.

Any help would be appreciated. I thought I should be using -atime or
-mtime but cannot seem to get the right sysntax.

TIA

Tony

[ Post a follow-up to this message ]

sorry for wasting everyones time, I found it

find . -name '*' -ctime +3 -print -exec rm {} \;

Tony wrote:
> Hi !
>
>
> I have inherited a system (macosx 10.4.3) where there is a directory
> that has lots of temp files being deposited daily.
>
> I do not want to delete all of these temp files, but I do want to prune
> them daily.
>
> What command line should I run to "find" all files that are over 3 days
> old and delete them.
>
> Any help would be appreciated. I thought I should be using -atime or
> -mtime but cannot seem to get the right sysntax.
>
> TIA
>
> Tony

[ Post a follow-up to this message ]

Tony wrote:
>
> sorry for wasting everyones time, I found it
>
> find . -name '*' -ctime +3 -print -exec rm {} \;

Maybe better to drop the -name clause so you include
names .* in the clean-up.  Definitely better to use
-mtime over -ctime for clean-up.  Change time is when
the inode changes (chown, chgrp, chmod and data
changes large enough to cause (de)allocations of data
blocks).  Modify time tracks data modification, more
likely to be what you want:

find temp_dir -type f -mtime +3 -print | xargs rm

Are there directories involved?  Some applications make
new directories like encoding the date in the directory
name and other characteristics in the filename.  Over
time you'll gradually build up many directories.  Every
so often you'll encounter an app that makes a new dir
every day or hour or whatever.  I like to clean those up
based on -mtime as well:

find temp_dir -depth -type d -mtime +3 -print | while read i ; do
COUNT=` /bin/ls -al ${i} | wc -l `
if [ $COUNT -gt 3 ] ; then
rmdir ${i}
fi
done

It's been a while since I typed in a loop to detect empty
dirs like that.  Is 3 right?  The "total" line, the "." line and
the ".." line.

If an app makes a deeply nested tree that will gradually
trim the empty directories, taking 3+ days at each level.

Of course if you separate out -type f and -type d like that,
you'll want to do something in case someone ever creates
symlinks, devices, pipes and such in the tree.  Doing that
will further exercise your find skills - the negation verb,
escaping stuff to keep it from being expanded by the
shell, likely even parens.

[ Post a follow-up to this message ]

On 15 Feb 2006 08:35:47 -0800, Doug Freyburger wrote:
> Tony wrote: 
>
> Maybe better to drop the -name clause so you include
> names .* in the clean-up.

With a UNIX conformant find, -name '*' has no effect, it will
not exclude dot files. Some old find implementations will not be
POSIX conformant and behave as you say. In any case, it's true
that it doesn't make sense to add "-name '*'".

> Definitely better to use
> -mtime over -ctime for clean-up.  Change time is when
> the inode changes (chown, chgrp, chmod and data
> changes large enough to cause (de)allocations of data
> blocks).


Any read or right to the file will modify the inode time as it
will change the atime or mtime, so modify the inode.

The ctime is modified at least everytime either of the other
times is modified.


> Modify time tracks data modification, more
> likely to be what you want:

Yes, though utime will modify it without any modification being
done, but that's on purpose.

> find temp_dir -depth -type d -mtime +3 -print | while read i ; do
>   COUNT=` /bin/ls -al ${i} | wc -l `
>   if [ $COUNT -gt 3 ] ; then
>     rmdir ${i}
>   fi
> done

Don't do such things on a temp dir, with world write access. If
that script is run by root, it's a security hole (it will
allow anyone to remove any empty directory in the system.

--
Stephane

[ Post a follow-up to this message ]

* Stephane Chazelas <stephane_chazelas@yahoo.fr>:

> The ctime is modified at least everytime either of the other
> times is modified.

No. Reading a file updates atime but not ctime.

- Andi

[ Post a follow-up to this message ]

Andreas Karrer wrote:
> Stephane Chazelas wrote:
> 
>
> No. Reading a file updates atime but not ctime.

Spelling "utime" with find.  I've always prefered calling it "atime"
but that doesn't work with find or the "-u" switch on ls.

It's a necessary feature that user access update utime but
not ctime.  Otherwise there would be no use to ctime.  It
would simply contain the higher of utime and mtime so it
would be redundant.

I'm not happy that ctime is affected by changes in the table
of blocks allocated to a file.  I get that extending a file enough
to need a new filesystem block will modify the inode and
ctime is intended to track changes to the inode, but i've long
wished that utime was for file access, mtime for file modification,
and utime was for modification of the user-accessible file
metadata not just modification of any of the metadata.

[ Post a follow-up to this message ]

2006-02-16, 08:23(-08), Doug Freyburger:
> Andreas Karrer wrote: 
>
> Spelling "utime" with find.  I've always prefered calling it "atime"
> but that doesn't work with find or the "-u" switch on ls.

What do you mean, there's no utime in find. There's a utime(2)
system call that can modify the atime or mtime, that is used for
instance by touch(1).
>
> It's a necessary feature that user access update utime but
> not ctime.  Otherwise there would be no use to ctime.  It
> would simply contain the higher of utime and mtime so it
> would be redundant.
>
> I'm not happy that ctime is affected by changes in the table
> of blocks allocated to a file.  I get that extending a file enough
> to need a new filesystem block will modify the inode and
> ctime is intended to track changes to the inode, but i've long
> wished that utime was for file access, mtime for file modification,
> and utime was for modification of the user-accessible file
> metadata not just modification of any of the metadata.
[...]

You're right about "read" access not updating ctime, even though
it modifies the inode since the atime is stored there.

But every write of at least 1 byte to a file should modify both
mtime and ctime, regardless of whether it causes a new block to
be allocated or even whether or not the file size is modified,
or even the file content is modified, that's what the Single
Unix Specification requires.

[url]http://www.opengroup.org/onlinepubs/009695399/functions/write.html#tag_03_866_03[/
url]

See also:

[url]http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_07[/
url]

--
Stéphane

[ Post a follow-up to this message ]