Unix Find Command results inconsistent

[wdellin]

I have a script that runs every 4 hours to find anything > today and compress it if it is not compressed. Some times it compresses all members in the directory that qualify and other times it does not. The script is executed from the cron. We have looked at the code and cannot see why it is acting the way it does. I rerun and it compresses the ones it missed before.
CRON................
0 00,04,08,12,16,20 * * * /tasc/bin/uxtar_log_cleanup.sh

SCRIPT uxtar_log_cleanup.sh

#!/bin/ksh
# Compress logs > 1 day old.
DTE=`date +%m%d%y%H%M`
LOGDIR="/tasc/logs"
LOGFILE=/tasc/logs/xstar_log_cleanup.log${DTE}

exec 1>$LOGFILE 2>&1
#
# compress members greater than 1 day in /tasc/logs
#
#
find ${LOGDIR} ! -name '*.Z' -mtime +0 -exec compress {} \;

DIRECTORY /tasc/logs
a few members after the scripts executed.


-rw-r--r-- 1 ustar ustar 960 Apr 6 05:08 RBMPsend_NEW040604042707.Z
-rw-r--r-- 1 ustar ustar 1824 Apr 6 05:28 ustar_processB.log.0406040528.Z
-rw-r--r-- 1 ustar ustar 1594 Apr 6 07:52 RBMPsend_NEW040604072503 <-Did not compress
-rw-r--r-- 1 ustar ustar 360 Apr 6 08:00 ustar_log_cleanup.log0406040800.Z

 

[alexhu]

find ${LOGDIR} ! -name '*.Z' -mtime +0 -exec compress {} \;

should you not be using -mtime +1 ?

Alex

 

[alexhu]

My message above may only apply to AIX

Alex

 

[wdellin]

My understanding is mtime +0 is for anything > 24 hours.

Probably should add that this is running on an old NCR server.

 

[hoinz]

Hi,
my understanding of mtime is the same as Alex's.
Of course your Unix my differ.
But why don't you just check it?
Enter these 3 commands, and see what you get:

find ${LOGDIR} ! -name '*.Z' -mtime +0
find ${LOGDIR} ! -name '*.Z' -mtime +1
ls -rtl ${LOGDIR}

regards

 

[wdellin]

results from mtime +0 and mtime +1 below. mtime +0 is the one I need.

xxxxx@xxxxxx:0:/tmp> find /tasc/logs/ ! -name '*.Z' -mtime +0 -exec ls -ld {}>
drwxr-xr-x 2 ustar ustar 4096 Mar 5 07:27 /tasc/logs/1996_logs
-rw-r--r-- 1 ustar ustar 1594 Apr 6 08:13 /tasc/logs/RBMPsend_NEW040604074302
-rw------- 1 ustar ustar 7421625 Apr 6 08:03 /tasc/logs/afpf040604g
-rw-r--r-- 1 ustar ustar 3323 Apr 6 08:26 /tasc/logs/ustar_processA.log.0406040826
-rw-r--r-- 1 ustar ustar 359 Apr 6 08:28 /tasc/logs/pre_migrate.sh.log.0406040600
drwxr-xr-x 2 ustar ustar 96 Mar 5 07:27 /tasc/logs/hold
-rw-r--r-- 1 ustar ustar 1610 Apr 6 09:03 /tasc/logs/RBMPsend_NEW040604090002
-rw------- 1 ustar ustar 3141 Apr 6 09:02 /tasc/logs/afpf040604h
-rw------- 1 ustar ustar 3141 Apr 6 09:03 /tasc/logs/afpf040604i
-rw-r--r-- 1 ustar ustar 30 Mar 12 2002 /tasc/logs/aa.sql
-rw-r--r-- 1 ustar ustar 2489 Apr 6 09:03 /tasc/logs/ustar_processA.log.0406040903
-rw-r--r-- 1 ustar ustar 358 Apr 6 09:15 /tasc/logs/pre_migrate.sh.log.0406040845
-rw-r--r-- 1 ustar ustar 199212 Mar 10 10:06 /tasc/logs/cold_ins.log
-rw-r--r-- 1 ustar ustar 529105 Mar 10 10:07 /tasc/logs/cold_parse.out
-rw-r--r-- 1 ustar ustar 8 Jan 5 2001 /tasc/logs/coldUnload
xxxxx@xxxxx:0:/tmp> find /tasc/logs/ ! -name '*.Z' -mtime +1 -exec ls -ld {}>
drwxr-xr-x 2 ustar ustar 4096 Mar 5 07:27 /tasc/logs/1996_logs
drwxr-xr-x 2 ustar ustar 96 Mar 5 07:27 /tasc/logs/hold
-rw-r--r-- 1 ustar ustar 30 Mar 12 2002 /tasc/logs/aa.sql
-rw-r--r-- 1 ustar ustar 199212 Mar 10 10:06 /tasc/logs/cold_ins.log
-rw-r--r-- 1 ustar ustar 529105 Mar 10 10:07 /tasc/logs/cold_parse.out
-rw-r--r-- 1 ustar ustar 8 Jan 5 2001 /tasc/logs/coldUnload

 

[alexhu]

AIX does recognise +0 but also brings up the '.' for current directory

But I don't get the inconsistency

/u04/archivelogs/pkms > ll
total 64280
drwxr-sr-x 2 oracle dba 131584 Apr 07 16:00 .
drwxrwsr-x 6 oracle dba 512 Dec 30 10:23 ..
-rw-r----- 1 oracle dba 3280929 Apr 06 16:16 arch0000046453.arc.Z
-rw-r----- 1 oracle dba 3017201 Apr 06 16:31 arch0000046454.arc.Z
-rw-r----- 1 oracle dba 1796351 Apr 06 23:52 arch0000046455.arc.Z
-rw-r----- 1 oracle dba 3794671 Apr 07 11:09 arch0000046456.arc.Z
-rw-r----- 1 oracle dba 3642221 Apr 07 13:17 arch0000046457.arc.Z
-rw-r----- 1 oracle dba 3313630 Apr 07 13:46 arch0000046458.arc.Z
-rw-r----- 1 oracle dba 3422677 Apr 07 15:37 arch0000046459.arc.Z
-rw-r----- 1 oracle dba 10486272 Apr 07 15:53 arch0000046460.arc
/u04/archivelogs/pkms > find . -mtime +1
./arch0000046453.arc.Z
/u04/archivelogs/pkms > find . -mtime +0
.
./arch0000046460.arc
./arch0000046455.arc.Z
./arch0000046456.arc.Z
./arch0000046458.arc.Z
./arch0000046453.arc.Z
./arch0000046454.arc.Z
./arch0000046457.arc.Z
./arch0000046459.arc.Z
/u04/archivelogs/pkms > date
Wed Apr 7 16:27:47 BST 2004

Alex

 

[wdellin]

Alex

That is the strange part, it does not always fail. The one
that just ran at 12:00 picked up everything correctly.

Is the find without a -type option the same as type -f? Looking for anything to possibly explain this inconsistency.

thanks for your time

 

[PHV]

Is the find without a -type option the same as type -f?
Obviously no. You get all the directory entries, but . and ..

Hope This Help, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884

 

[aigles]

Are you sure that the files are not in use ?
The problem comes perhaps from the compress command.

Jean Pierre.

 

[wdellin]

I'm not aware of them being in use. Only the compress accesses members > 24 hours on this directory. Other jobs are writting to this directory but have current dates.

 

[Salem]

A couple of things come to mind.

Produce a list of files which the find command found.

find ${LOGDIR} ! -name '*.Z' -mtime +0 > tmp$$  # produce a list
compress -v `cat tmp$$`  # compress them all
echo 'The File List'
cat tmp$$                # dump the list in $LOGFILE
rm -f tmp$$              # cleanup

The -v is the verbose option, which should tell you more about what compress is up to.

> 1594 Apr 6 07:52 RBMPsend_NEW040604072503 <-Did not compress
Small files in particular can end up bigger due to the overhead of storing some additional information necessary to decompress the file later. When compress detects this situation, the file is not compressed.
Though this doesn't really explain why it compresses OK later on.

Another question
Is something being confused by the -mtime +0 ?
I'm wondering if this is only a problem for the midnight run, and the potential confusion of perhaps finding files which are 1 day old at the changeover from one day to the next.
Do you only get these missed files in the midnight run, or does it affect all of them?

Can you also paste some relevant lines out of $LOGFILE

--

 

[wdellin]

This situation has occurred during any of the runs, 4:00 8:00, etc. As far as the $LOGFILE, there are currently no relevant lines for the compress.

The code was compress if the name is not *.Z with no output.