TAR command setting file modified date

[John O'Neill_6]

Hi all,

I'm trying to use the 'find -mtime + ...' utility to pick up files older than days old to move to a directory where they will be deleted.

I have two HP UX11i systems here, one is running a slightly more recent update.

On the first machine it works fine.

On the second machine, I am finding that my daily TAR backup of the directory in question is modifying the 'modified time' of the files, so the -mtime + option on the 'find' statement naturally won't return anything.

My tar command in my backup script it:

cd /
tar -cf /dev/rmt/0mn

It's the SAME command on both boxes, on one box it modifies the time on the other it doesn't.

So, is there an option for TAR which will instruct it to specifically NOT modify the date/time stamp on the files which it is backing up?

This is most annoying...

Any help appreciated.

-John O'Neill

[Muthukumar_5]

Are you saying that you are just taking backup using tar and it is modifying file modification time?

Can you do sample work on maching with problem as,
cd /tmp
touch 200312010100 file.1
touch 200312010200 file.2

check ls -l file.*

tar -cvf test.tar file.*

check ls -l file.*

post the both.

hth.

[TwoProc]

John that is unusual behavior.

I'm thinking it is a) a bug, or b) something else in your script is touching those files.

do a

what `which tar`

on both machines and compare the versions please, and tell us the results.

[TwoProc]

Or, maybe another script that is trolling over this directory at a closely related time/event is touching the files?

[Pete Randall]

John,

It seems to me I remember that there used to be a note in the man page for find to the effect that running the find command affected the access? time of the files it traversed. Check your versions of find to see if one has had patches applied:

what /usr/bin/find


Pete

[John O'Neill_6]

Thanks for replies everyone.

Well... here the result from our live machine.

22183 what /usr/bin/find
/usr/bin/find:
$Revision: B.11.11_LR
Fri Oct 27 00:57:17 PDT 2000 $

That's it, that's all it says.

Here's the result from our dev/dr machine.

$ what /usr/bin/find
/usr/bin/find:
find.c $Date: 2002/02/05 22:05:26 $Revision: r11.11/2 PATCH_11.11 (PHCO_25905)
funcs.c $Date: 2002/02/09 04:05:22 $Revision: r11.11/2 PATCH_11.11 (PHCO_25905)
$Revision: @(#) find CUP11.11_BL2002_0213_2 PATCH_11.11 PHCO_25905
Wed Feb 13 07:05:23 PST 2002 $

The DEV machine seems to return more up to date info than the live machine.

I have to admit, I'm begining to loose confidence in the HP UX Platform with each passing month.

Any advice is appreciated, I'll speak to our local HP re-seller who we deal with quite often and get someone out onsite to assist.

Thanks all, any further info appreciated, allocating points now.

-John O'Neill

[Bill Hassell]

The find command on the problem machine is not patched at all and the OK machine is two versions behind. The current patch is PHCO_30746. But it's not likely to be a find problem if after the backup, the files all have the current date/time from the ls -l command. I would check the tar revision (should be PHCO_28992).

Now if the actual timestamp reported by ll is unchanged then it would point back to find as the problem. -mtime is creation or content modification time. -atime is much more volatile. Any backup will change the access time all files and directories.

In either case, I would review your patch strategy since the production machine may be more than 2 years out of date. Like any opsystem, patche bundles are required every 3-6 months.

[John O'Neill_6]

Hi,

Thanks.

I've got a request in to get our patches on the prod box sorted out. When it was recently rebuilt, the CD's the HP rep used to install the operating system were dated mid to late 2004.

I'll let you know how we go.

Ideally I want to patch every quarter for patches that are known to be good and have been live for 120 days.

However trying to download patch bundles from the website is very difficult, downloads fail all the time.

-John O'Neill