Incorrect find * -ctime +7

[Andrew S. Chipalyuk]

I have used Tru64 UNIX V5.1B PK5.
I removed my old system logs (syslog.dated) by default system cron shell command:
find /var/adm/syslog.dated/* -depth -type d -ctime +7 -exec rm -rf {} \;
Recently the find command didn't run correctly with key -ctime.
It find nothing when i am runnig:

# find /var/adm/syslog.dated/* -depth -type d -ctime +7

but it find files changed in the past 7 days when i am runnig:
# ls -lt
total 432
drwxr-xr-x 2 root adm 8192 Feb 12 08:53 12-Feb-08:53
lrwxr-xr-x 1 root adm 12 Feb 12 08:53 current -> 12-Feb-08:53
drwxr-xr-x 2 root adm 8192 Feb 11 08:53 11-Feb-08:53
drwxr-xr-x 2 root adm 8192 Feb 10 08:53 10-Feb-08:53
drwxr-xr-x 2 root adm 8192 Feb 9 08:52 09-Feb-08:52
drwxr-xr-x 2 root adm 8192 Feb 9 03:01 09-Feb-03:01
drwxr-xr-x 2 root adm 8192 Feb 8 03:00 08-Feb-03:00
drwxr-xr-x 2 root adm 8192 Feb 7 03:00 07-Feb-03:00
drwxr-xr-x 2 root adm 8192 Feb 6 02:59 06-Feb-02:59
drwxr-xr-x 2 root adm 8192 Feb 5 02:59 05-Feb-02:59
drwxr-xr-x 2 root adm 8192 Feb 4 02:58 04-Feb-02:58
drwxr-xr-x 2 root adm 8192 Feb 3 02:58 03-Feb-02:58
...

What was happening? How repair this problem?

[Ivan Ferreira]

Use -mtime instead of -ctime. -mtime is the modification time of the file, and -ctime is the inode modification time.

[Andrew S. Chipalyuk]

Thank you!
Yes, it functions fine really!
But why have used the default cron command -ctime instead of -mtime? Is default cron command incorrect?

# grep find /var/spool/cron/crontabs/root
40 4 * * * find /var/adm/syslog.dated/* -depth -type d -ctime +7 -exec rm -rf {} \;

[Hein van den Heuvel]

>> Thank you!
>> Yes, it functions fine really!

Of course! You did not really think something so fundamental would be broken, did you?!?

>> But why have used the default cron command -ctime instead of -mtime?

Probably because the test is on a Directory, not a common datafile for which -mtime is the common test.

The missing information in the base topic it the output from 'ls -ltc' vs plain 'ls -lt'.
The base topic shows the plain -lt which corresponds with 'mtime'.

Had the -ltc output been requested, then the consistency of the find would surely have become clear.

>> Is default cron command incorrect?
Are you use it is a default, Tru64 command, not just a commonly used command set up by a sysadmin in long forgotten times?
Note, I'm not saying you are right or wrong, I simply did not know Tru64 provided this 'out of the box'. Next time I'll boot my Tru64 setup I'll have to look!

Regards,
Hein.

[Andrew S. Chipalyuk]

No, i do not think something so fundamental would be broken.
Yes, i am using default.
In really i can see time of last inode modification is a current day!

# ls -ltc
total 440
drwxr-xr-x 2 root adm 8192 Feb 13 08:54 13-Feb-08:54
lrwxr-xr-x 1 root adm 12 Feb 13 08:54 current -> 13-Feb-08:54
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 01-Feb-02:57
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 02-Feb-02:58
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 03-Feb-02:58
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 04-Feb-02:58
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 05-Feb-02:59
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 06-Feb-02:59
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 07-Feb-03:00
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 08-Feb-03:00
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 09-Feb-03:01
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 09-Feb-08:52
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 10-Feb-08:53
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 11-Feb-08:53
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 12-Feb-08:53
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 17-Jan-02:51
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 18-Jan-02:51
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 19-Jan-02:52
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 20-Jan-02:52
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 21-Jan-02:53
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 22-Jan-02:53
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 23-Jan-02:53
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 24-Jan-02:54
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 25-Jan-02:54
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 26-Jan-02:55
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 27-Jan-02:55
drwxr-xr-x 2 root adm 8192 Feb 13 04:12 28-Jan-02:55
....

I don't know, why is inode time modifieing every day?
I have one more Tru64 server, when i can see different result of commant 'ls -ltc':

# ls -ltc
total 56
drwxr-xr-x 2 root adm 8192 Feb 12 16:48 12-Feb-16:48
lrwxr-xr-x 1 root adm 12 Feb 12 16:48 current -> 12-Feb-16:48
drwxr-xr-x 2 root adm 8192 Feb 11 16:48 11-Feb-16:48
drwxr-xr-x 2 root adm 8192 Feb 10 16:43 10-Feb-16:43
drwxr-xr-x 2 root adm 8192 Feb 9 16:43 09-Feb-16:43
drwxr-xr-x 2 root adm 8192 Feb 8 16:42 08-Feb-16:42
drwxr-xr-x 2 root adm 8192 Feb 7 16:42 07-Feb-16:42
drwxr-xr-x 2 root adm 8192 Feb 6 16:42 06-Feb-16:42

[Hein van den Heuvel]

>> In really i can see time of last inode modification is a current day!

So now we are getting somewhere.

The original find now even more clearly did the right thing by not finding anything older than x days because eevrythign was touched 'today'

The subtle question of whether to use ctime or mtime is now moot and replaced by a much more concrete question:

Which script is modifying the syslog.dated sub directory every single day @ 4:12 in the morning, on this one system.

The cron files will surely point to just a few scripts to verify.

Is one of them re-trying to compress some content of all the sub directories every day? Or doing a cd into them and running a report? Or for some reason beyond or current comprehension issueing a 'touch'?

Hein.

[Andrew S. Chipalyuk]

Today the inode time of syslog.dated sub directory and files was modifying 02:58 in the morning. Now i am trying to find script is it doing. But for all that the content sub directorys and files is not modifying.