wrong timestamp on tar -xvf

[Kevin Tucker]

I was wondering if anyone has seen the following problem.

I have a tar file on my HP-UX 11.11 system. When I extract it (tar -xvf), all the files lay down fine BUT the modification timestamp on ALL of the directories changes to the current day and time. The individual files keep their original timestamp.
I thought that tar was supposed to keep ALL of the modification timestamps on ALL of the files.
Here is my extraction command:

tar -xvf ../CD8.tar

Any help would be greatly appreciated. Thanks in advance.

[A. Clay Stephenson]

This is the normal behavior for tar --- if you stop to think about it a moment it makes sense. Tar does not restore everything exactly; it can't. The source and destination filesystems might be of completely different types and at the very least, inode numbers would change. Each file is restored individually and as part of the restoration a UNIX creat() system call is done and that makes a new directory entry; each one of these updates the modification metadata for that directory. The timestamp metadata for regular files is preserved but for directories this timestamp data would truly be a lie.

[Kevin Tucker]

Your answer makes sense BUT when I pull the tar file over to another platform, the tar command KEEPS the modification timestamp for ALL of the directories AND files.
I tried this on Solaris, IBM AIX and LINUX.
I know that this has worked before on HP-UX version 10.20. Did HP change the way tar works for HP 11.00 and/or 11.11??

[Navin Bhat_2]

good point. Tar initially extracts to the original timestamp (mtime atime ctime) but when it starts to extracts the files the metadata information changes hence the times will get updated.

I tar'd a directory with no files and tar xvf the directory everything was preserved.

When I tried the same with a file in the directory the timestamps got updated.


root:[/tmp/x]>tar cvf t.tar lost+found

root:[/tmp]>mkdir x
root:[/tmp]>cd x
root:[/tmp/x]>ll
total 0
root:[/tmp/x]>mv ../t.tar .

root:[/tmp/x]>ll
total 20
-rw-rw-rw- 1 root sys 10240 May 14 11:49 t.tar

root:[/tmp/x]>tar xvf ./t.tar

root:[/tmp/x]>ll
total 20
drwxr-xr-x 2 root root 96 Mar 5 2003 lost+found
-rw-rw-rw- 1 root sys 10240 May 14 11:49 t.tar

[Lee Hundley]

According to the tar(1) man page, it should:

(found in the description of the 'x' command)
+ The modification time is restored from the tape unless the m function modifier is specified.

I just tested it on a 11i machine by untarring the gnupg source, and it restored the date/timestamps as the man page describes. Check to make sure you're not using GNU's tar, which may behave differently.

[Navin Bhat_2]

Hello Kevin,
I tested on a 10.20 system the behaviour is the same.

# tar xvf f.tar

# ll
total 8
dr-xr-xr-x 2 root other 24 May 28 1999 dist
dr-xr-xr-x 2 root other 1024 May 14 12:18 etc

# ll -R

./dist:
total 0

./etc:
total 6
-r--r--r-- 2 root other 209 May 28 1999 group
-r--r--r-- 2 root other 209 May 28 1999 logingroup
-r--r--r-- 1 root other 970 May 28 1999 passwd

[Kevin Tucker]

I know that tar is SUPPOSE to keep the mod. dates and times but on my machine it is not.
I was wondering if anyone knew of any environment variable that could be set that could cause this or something in the kernel maybe.

[Navin Bhat_2]

I dont think you can do that for directories with files in it.

[Navin Bhat_2]

Hi Kevin,


Ok I was able to do it. But not using tar.

I used the "pax" command.

# pax -w -f paxed.file

# pax -rv < paxed.file

It preserved the directory timestamps.

Maybe you can use this as an alternate procedure.

[Kevin Tucker]

Ok. Here is some sample output.
The orig.txt file contains the tar -tvf output of the files that I used. This file contains the CORRECT timestamps for the file.

The second file, tar.txt contains the output of a file listing AFTER I performed a tar -xvf on the tar file. This output has the INCORRECT timestamps for several directories.

[Navin Bhat_2]

Did you miss the attachments orig.txt and tar.txt?

[Kevin Tucker]

I had trouble attaching them so I will post them here:

orig.txt:
rwxrwxrwx 2/2 0 May 10 16:44 2004 ./usr/local/
rwxrwxrwx 2/2 0 May 10 16:44 2004 ./usr/local/man/
rwxr-xr-x 0/3 0 May 10 16:44 2004 ./usr/local/man/man1/
rw-r--r-- 0/3 52219 Dec 11 07:14 2003 ./usr/local/man/man1/rsync.1
rwxr-xr-x 0/3 0 May 10 16:44 2004 ./usr/local/man/man5/
rw-r--r-- 0/3 21508 Dec 11 07:14 2003 ./usr/local/man/man5/rsyncd.conf.5
rwxrwxrwx 2/2 0 May 10 16:44 2004 ./usr/local/bin/
rwxr-xr-x 0/3 274432 Dec 11 07:14 2003 ./usr/local/bin/rsync
rwxrwxrwx 2/2 0 Apr 29 18:25 2004 ./usr/local/etc/
rwxrwxrwx 2/2 0 Apr 29 18:25 2004 ./usr/local/games/
rwxrwxrwx 2/2 0 Apr 29 18:25 2004 ./usr/local/lib/
rwxr-xr-x 0/3 0 May 10 16:44 2004 ./usr/local/doc/
rwxr-xr-x 0/3 0 May 10 16:44 2004 ./usr/local/doc/rsync/
rwxr--r-- 0/3 17982 Dec 11 07:14 2003 ./usr/local/doc/rsync/COPYING
rwxr--r-- 0/3 1744 Dec 11 07:14 2003 ./usr/local/doc/rsync/HPUX.Install
rwxr--r-- 0/3 1249 Dec 11 07:14 2003 ./usr/local/doc/rsync/INSTALL
rwxr--r-- 0/3 3488 Dec 11 07:14 2003 ./usr/local/doc/rsync/NEWS
rwxr--r-- 0/3 3734 Dec 11 07:14 2003 ./usr/local/doc/rsync/README
rwxr--r-- 0/3 26095 Dec 11 07:14 2003 ./usr/local/doc/rsync/TODO

tar.txt

total 0
drwxrwxrwx 3 bin bin 96 May 14 15:40 usr

./usr:
total 2
drwxrwxrwx 8 bin bin 1024 May 14 15:40 local

./usr/local:
total 0
drwxrwxrwx 2 bin bin 96 May 14 15:40 bin
drwxr-xr-x 3 root sys 96 May 14 15:40 doc
drwxrwxrwx 2 bin bin 96 Apr 29 18:25 etc
drwxrwxrwx 2 bin bin 96 Apr 29 18:25 games
drwxrwxrwx 2 bin bin 96 Apr 29 18:25 lib
drwxrwxrwx 4 bin bin 96 May 14 15:40 man

./usr/local/bin:
total 536
-rwxr-xr-x 1 root sys 274432 Dec 11 07:14 rsync

./usr/local/doc:
total 2
drwxr-xr-x 2 root sys 1024 May 14 15:40 rsync

./usr/local/doc/rsync:
total 112
-rwxr--r-- 1 root sys 17982 Dec 11 07:14 COPYING
-rwxr--r-- 1 root sys 1744 Dec 11 07:14 HPUX.Install
-rwxr--r-- 1 root sys 1249 Dec 11 07:14 INSTALL
-rwxr--r-- 1 root sys 3488 Dec 11 07:14 NEWS
-rwxr--r-- 1 root sys 3734 Dec 11 07:14 README
-rwxr--r-- 1 root sys 26095 Dec 11 07:14 TODO

./usr/local/etc:
total 0

./usr/local/games:
total 0

./usr/local/lib:
total 0

./usr/local/man:
total 0
drwxr-xr-x 2 root sys 96 May 14 15:40 man1
drwxr-xr-x 2 root sys 96 May 14 15:40 man5

./usr/local/man/man1:
total 102
-rw-r--r-- 1 root sys 52219 Dec 11 07:14 rsync.1

./usr/local/man/man5:
total 44
-rw-r--r-- 1 root sys 21508 Dec 11 07:14 rsyncd.conf.5

[Navin Bhat_2]

Yes this is what we tried to say earlier that the directories with no files or sub directories will preserve the timestamp like

/usr/local/
drwxrwxrwx 2 bin bin 96 Apr 29 18:25 etc
drwxrwxrwx 2 bin bin 96 Apr 29 18:25 games

./usr/local/etc:
total 0

./usr/local/games:
total 0

------
While the directories with further subdirectories or files will show the current timestamp.

./usr/local/man:
total 0
drwxr-xr-x 2 root sys 96 May 14 15:40 man1
drwxr-xr-x 2 root sys 96 May 14 15:40 man5

./usr/local/man/man1:
total 102
-rw-r--r-- 1 root sys 52219 Dec 11 07:14 rsync.1

[Kevin Tucker]

I see your point BUT this is NOT how tar works in the rest of the world. I have tried several tar tests on many other platforms, SUN, AIX, LINUX and they all work the same. ALL of the permissions are restored.
I just want to know why HP decided to be different and purposely changed the way TAR works. This is broken.

[Juergen Tappe]

Just a thought,
are you executing the tar as root?
if not it could be tar cannot change time back because the ownership has changed and the direcories not anymore yours....

[Kevin Tucker]

Yes, I am logged in as root. I have checked this on various HP machines and it seems that they all do the same thing. Whenever they extract a directory from a tar image, they update the modification timestamp on the directory to the current time and day.
Although this may seem logical, it goes against what the MAN pages state as the functionality of TAR.
Also, from what I can tell, HP is the ONLY platform that does this and I cannot understand WHY???!!!! It is starting to get annoying.
I did notice that if I use the PAX utility, it DOES restore the correct timestamp, but WHY would I have to EVEN consider using PAX when the MAN pages on HP tell me TAR should work????????!!!!!!!

This is getting VERY frustrating.
Does anyone know WHY HP does this????

[Navin Bhat_2]

Hello Kevin,

There is no "standard" for tar behavior and each OS can choose to behave it its own way.

In any case I tested this feature on all the os versions. Only 10.01 had the feature where the directory permissions were preserved again which was available through a patch.

I have logged a bug/enhancement report and will let you know in a few days through this thread if and when they release a patch to satisfy this requirement.

Thx - Navin.