need to remove files older that 1 day

[Donald Thaler]

using the following command:
find /u03/oradata/archive/*.dbf -mtime +1 -exec rm -f {} \; -print

yet i see files in the directory that are from 1/18, today is 1/20.. only want to keep files for 1 day... is there a different option that can be used...

sorry if this is a duplicate... i added it about 10 minutes ago and don't see it on the website ..

[Steven E. Protter]

Shalom,

The command seems adequate. You want to use modify mtime unless you know the files can go, in which case you can try the ctime option.

SEP

[James R. Ferguson · Accepted solution]

Hi Donald:

Using '-mtime +1' means to return true if the modification time is larger than 'n' or in this case larger than one (1). The interval in question is a 24-hour one.

That said your 'find' command should also be amended to look only for _files_ and to match the file basename by using the '-name' option. Performance can also be improved by buffering many arguments to 'rm' by changing the trailing delimiter from '\;' to '+'. In all:

# find /u03/oradata/archive -type f -name "*.dbf" -mtime +1 -exec rm -f {} +

Notice that I dropped the '-print' as it is superfluous and out of place.

The '-name' argument is double-quoted to prevent the shell from expanding it; passing it to 'find' for evaluation.

The '-type f' restricts the evaluation to only files and prevents you potentially searching and returning directories that have been modified in the specified time but otherwise have no _file_ candidates to return.

The performance can be greatly increased by changing the delimiter from '\;' to '+'. In this fashion, one 'rm' command will be spawned with multiple file arguments instead of one 'rm' command for _every_ file argument.

Regards!

...JRF...

[Dennis Handly]

>find /u03/oradata/archive/*.dbf -mtime +1 -exec rm -f {} \; -print

You'll want to replace "\;" by just "+" for performance.

>yet i see files in the directory that are from 1/18, today is 1/20. only want to keep files for 1 day.

If you only want to keep less than 24 hours, you can use: -time +0

>sorry if this is a duplicate.

I don't see one.

[Dennis Handly]

>JRF: Using '-mtime +1' means to return true if the modification time is larger than 'n' or in this case larger than one (1).

So that means it finds it only if 2 days or more. (Assuming UNIX95=FIDDLE_WITH_FIND_TIMES isn't set.)

>match the file basename by using the '-name' option.

Why? You think find(1) is faster than the shell? Of course if there are too many files, you are correct.

>Notice that I dropped the '-print' as it is superfluous and out of place.

I didn't make that assumption. Perhaps Donald wanted a list? (I assumed that because it was out of place.)

[TTr]

If you look at the files from 1/18 you will see that their age is less than 48 hours. This is how the "-mtime +1" works. If it is less than 2 days old the "+1" condition is satisfied. You should either accept this or if you really want to delete more files, you can try this

find /path/to/files/*.dbf -mtime +0 -exec ll -d \;

Note that instead of the "rm" command I use the "ll -d" command to see which files get selected. After you verify the files, you can replace the "ll -d" with "rm". To be even safer enhance the command by adding a "-type f"

[Donald Thaler]

when i try the -time +0 i get 'bad option -time' ?

when i try:
find /u03/oradata/archive/*.dbf -mtime +0 -exec ll -d \;

it's getting all the .dbf files up to the current time, i understood that i would only get files that were 1 day old ??

[TTr]

> when i try the -time +0 i get 'bad option -time' ?

The option for the find command is "mtime" not "time". That was a typo by Dennis.

"-mtime +0" means anything "older than 0 days". This means if a file is 23h59m is zero days old and will not be selected.

[Dennis Handly]

>when I try the -time +0 I get 'bad option -time'?

Sorry, a typo, that's "-mtime +0"

>when I try: find /u03/oradata/archive/*.dbf -mtime +0 -exec ll -d \;
>it's getting all the .dbf files up to the current time

You shouldn't unless you exported UNIX95=FIDDLE_WITH_FIND_TIMES.
As TTr mentioned this is based on 24 hours from the time you start find(1), not midnight.

[Donald Thaler]

whats the value i would use in mtime to retrieve files dated 1/19... when i use +0 i get todays files 1/20, when i use +1 i get nothing and i know there are file date 1/19 ???

[Dennis Handly]

>what's the value I would use in -mtime to retrieve files dated 1/19

That's not what -mtime does. It uses the reference time, not midnight. If you want a date range, you must use -newer.
See these threads where there are:
( -newer temp1.touch -a ! -newer temp2.touch \)
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1254376
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1139965

>when I use +0 I get today's files 1/20

When you use +0, you get all files that have not been modified in the last 24 hours.

>when I use +1 I get nothing and I know there are file date 1/19?

When you use +1, you get all files not modified in the last 48 hours.

If you still have questions, please provide the current date & time and ll(1) on the files:
date; ll *.dbf

[Yogeeraj_1]

hi Donald,

are you trying to purge Oracle archived redolog files?

if yes, there are much cleaner ways of managing such files. Read about RMAN and retention options.

if you need any further assistance, please let us know.

kind regards
yogeeraj

[James R. Ferguson]

Hi (again) Donald:

> Dennis: (Assuming UNIX95=FIDDLE_WITH_FIND_TIMES isn't set.)

Agreed; Occam's razor.

> Dennis: match the file basename by using the '-name' option. Why? You think find(1) is faster than the shell? Of course if there are too many files, you are correct.

It isn't about speed, it's about whether or not he wants to descend the directory and process subdirectories, or he wants to confine himself to the top level directory.

> Dennis: Notice that I dropped the '-print' as it is superfluous and out of place. I didn't make that assumption. Perhaps Donald wanted a list? (I assumed that because it was out of place.)

I was wrong on this. I hadn't considered placing the '-print' after an '-exec', though clearly is is viable and would indeed force a listing of what was removed. I can only say that I would have written the '-exec' and its arguments as the last piece.

Regards!

...JRF...

[Steve Post]

There is another way to get files within a set time frame. I suprised it wasn't brought up. Perhaps there is something wrong with it I don't know about?

to find files newer than 20Jan2009 8am and older than 21Jan2009 8am
touch -t YYYYMMddHHmm ./filename

cd /u03/oradata/archive
touch -t 200901200800 ./before
touch -t 200901210800 ./after
find . \( -newer ./before -a ! -newer ./after \) -type f -name "*.dbf" -exec rm -f {} +
rm ./before
rm ./after

And that + is great. I never knew that. And I've been using find for many years. If you have an extremely large number of files to delete (astronomically big that is) I suspect it would complain about too many arguments?

[TTr]

@ Steve: > I suprised it wasn't brought up.

Did you read Dennis' reply, 3rd reply above your reply? He does mention the newer option and 2 URL that have a lot more details on the newer and "older" options.

Donald's original question was "... files older than 1 day", It was changed later on but at this point I am not sure what he is after.not

[Steve Post]

yep. I didn't see that 3 replies up.

But at least I provided the syntax of the touch command. And even though the guy didn't ask it, you might be surprised how many times I got answers to questions I didn't ask (yesterday). It is most of the time. And sometimes a side step can provide a faster, simplier safer solution.

[Dennis Handly]

>Steve: I surprised it wasn't brought up.

Those were in the links I mentioned.

>If you have an extremely large number of files to delete. I suspect it would complain about too many arguments?

Yes. You could fix this as JRF said.

>But at least I provided the syntax of the touch command.

That was also in the links.

[Steve Post]

ok. thanks. I'll stop writing until I read all the posts and all the links.

[Steve Post]

....most of the time. It seems a bit silly to be denied the ability to help a person, just because I didn't read all the text and follow all the links.

Since I'll never please everyone anyhow. So I'll do what I want.... which is... in my mind... to attempt to be helpful.

Besides. My normal points for answers is: Unassigned.

[Hein van den Heuvel]

Steve>> Besides. My normal points for answers is: Unassigned.

Confirmed :-).

Dennis>> Assuming UNIX95=FIDDLE_WITH_FIND_TIMES isn't set.

Ok, I give up. I first looked in some man pages, then I googled, searched HP.com (useless), searched the current hpux docs in pdf, even askes Jeeves. No hint on this option. Please explain!


yogeeraj> are you trying to purge Oracle archived redolog files?

That's what I was thinking.

yogeeraj>> if yes, there are much cleaner ways of managing such files. Read about RMAN and retention options.

That might be the best answer yet.


Donald, perhaps CLOSE this topic with a quick summary of what helped you best?

Hein.

[James R. Ferguson]

Hi (again) Donald:

@ Hein - See the dialog in:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1233150720817+28353475&threadId=1271016

...AND my comments about UNIX95 settings in:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1276190

...and then you will see "why"...

Regards!

...JRF...

[Hein van den Heuvel]

Ah, I see. I parsed the sentence the wrong way.

I should have read; Assuming UNIX95 is not set, which tells the system to 'FIDDLE_WITH_FIND_TIMES'. See ...

Silly enough I read it as UNIX95 had to be given the specific value FIDDLE_WITH_FIND_TIMES where I did not stop to think how that could be, where that value would be defined, other than in a geekish mind.

:-)

[Dennis Handly]

>Hein: >>Assuming UNIX95=FIDDLE_WITH_FIND_TIMES isn't set.

>I first looked in some man pages

This option says what it does. :-)
You just need to wait until I use it a few more times like "zombie master" and UNIX95=EXTENDED_PS_FEATURES.

>JRF: @ Hein - See the dialog in:

Right. I had to use google to find this.

>JRF: AND my comments about UNIX95 settings in:

That I found with forums advanced search.

>Hein: I should have read; Assuming UNIX95 is not set, which tells the system to 'FIDDLE_WITH_FIND_TIMES'.

No, just the opposite. If it IS set it fiddles with the times as incorrectly documented. If not set, it does the divide and truncate.

>Silly enough I read it as UNIX95 had to be given the specific value FIDDLE_WITH_FIND_TIMES

That's exactly what I meant. It should be set like that, then you know what it does.

>where that value would be defined, other than in a geekish mind.

Well, a language lawyer where you need to make N logical inferences. :-)