restoring a tar archive && modification time of directories

[Matthias Apitz]

Hello,

I do backups with something like 'tar cfz home.tgz home' and today due
to an emergency I was lucky to have such backups and did a restore with
something like 'tar xzf home.tgz'. I was suprised that now all
diretories have the today modificatguru/Adaion time, like this:

$ ls -ld Ada
drwxr-xr-x 2 guru wheel 512 1 may. 11:31 Ada
$ ls -l Ada
total 1008
-rwxr-xr-x 1 guru wheel 977936 27 feb. 2016 hello
-rw-r--r-- 1 guru wheel 124 27 feb. 2016 hello.adb
-rw-r--r-- 1 guru wheel 1630 27 feb. 2016 hello.ali
-rw-r--r-- 1 guru wheel 1608 27 feb. 2016 hello.o
-rw-r--r-- 1 guru wheel 120 27 feb. 2016 hello.txt

In the tar archive the directory 'Ada' looks like this:

$ grep guru/Ada guru-20250501.tar.gz.lst
drwxr-xr-x 0 guru wheel 0 8 Dez. 2020 guru/Ada/
-rw-r--r-- 0 guru wheel 124 27 Feb. 2016 guru/Ada/hello.adb
-rw-r--r-- 0 guru wheel 1630 27 Feb. 2016 guru/Ada/hello.ali
-rw-r--r-- 0 guru wheel 1608 27 Feb. 2016 guru/Ada/hello.o
-rwxr-xr-x 0 guru wheel 977936 27 Feb. 2016 guru/Ada/hello
-rw-r--r-- 0 guru wheel 120 27 Feb. 2016 guru/Ada/hello.txt

Why is the directory guru/Ada/ not set to 8 Dez. 2020 after restoring
the files into it? Is this a bug in our bsdtar?

Thx

matthias


--
Matthias Apitz, ✉ gu...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

An die deutsche Bundesregierung: Nein, meine Söhne geb' ich nicht für Ihren Krieg!
Al Gobierno alemán: ¡No, no doy mis hijos para su guerra!
To the German Government: No, I will not give my sons for your war!

[Kurt Hackenberg]

On Thu, May 01, 2025 at 05:04:12PM +0200, Matthias Apitz wrote:

>Why is the directory guru/Ada/ not set to 8 Dez. 2020 after restoring
>the files into it?

Did you run tar as root?

[Matthias Apitz]

Yes, in both cases.

[Bob Proulx]

Matthias Apitz wrote:
> Why is the directory guru/Ada/ not set to 8 Dez. 2020 after restoring
> the files into it? Is this a bug in our bsdtar?

This worked for me when I tried it. I tried it on 14.2R with both
/usr/bin/tar and /usr/local/bin/bsdtar and both produced the desired
result.

I did this to test it.

rwp@madness:~/tmp/junk$ rm -rf dir1
rwp@madness:~/tmp/junk$ mkdir dir1
rwp@madness:~/tmp/junk$ touch -t 197001010101 dir1/file2 dir1
rwp@madness:~/tmp/junk$ ls -lRa dir1
total 2
drwxr-xr-x 2 rwp rwp 3 Jan 1 1970 ./
drwxr-xr-x 4 rwp rwp 5 May 1 11:15 ../
-rw-r--r-- 1 rwp rwp 0 Jan 1 1970 file2
rwp@madness:~/tmp/junk$ type -p tar
/usr/bin/tar
rwp@madness:~/tmp/junk$ tar czf dir1.tar.gz dir1
rwp@madness:~/tmp/junk$ file dir1.tar.gz
dir1.tar.gz: gzip compressed data, last modified: Thu May 1 17:17:31 2025, from Unix, original size modulo 2^32 2048
rwp@madness:~/tmp/junk$ tar tvf dir1.tar.gz
drwxr-xr-x 0 rwp rwp 0 Jan 1 1970 dir1/
-rw-r--r-- 0 rwp rwp 0 Jan 1 1970 dir1/file2
rwp@madness:~/tmp/junk$ bsdtar tvf dir1.tar.gz
drwxr-xr-x 0 rwp rwp 0 Jan 1 1970 dir1/
-rw-r--r-- 0 rwp rwp 0 Jan 1 1970 dir1/file2
rwp@madness:~/tmp/junk$ rm -rf dir1
rwp@madness:~/tmp/junk$ tar xf dir1.tar.gz
rwp@madness:~/tmp/junk$ ls -lRa dir1
total 2
drwxr-xr-x 2 rwp rwp 3 Jan 1 1970 ./
drwxr-xr-x 3 rwp rwp 4 May 1 11:18 ../
-rw-r--r-- 1 rwp rwp 0 Jan 1 1970 file2
rwp@madness:~/tmp/junk$ rm -rf dir1
rwp@madness:~/tmp/junk$ bsdtar xf dir1.tar.gz
rwp@madness:~/tmp/junk$ ls -lRa dir1
total 2
drwxr-xr-x 2 rwp rwp 3 Jan 1 1970 ./
drwxr-xr-x 3 rwp rwp 4 May 1 11:19 ../
-rw-r--r-- 1 rwp rwp 0 Jan 1 1970 file2
rwp@madness:~/tmp/junk$ df -hT .
Filesystem Type Size Used Avail Capacity Mounted on
zroot/home/rwp zfs 1.4T 189G 1.2T 14% /home/rwp
rwp@madness:~/tmp/junk$ freebsd-version -ku
14.1-RELEASE-p5
14.1-RELEASE-p6

Could you test this more on your system?

Bob

[Matthias Apitz]

I can ACK the example of Bob with:

$ rm -r d
$ mkdir d
$ touch -t 202504300101 d/file d
$ ls -ld d d/file
drwxr-xr-x 2 guru wheel 512 30 abr. 01:01 d
-rw-r--r-- 1 guru wheel 0 30 abr. 01:01 d/file
$ tar cf d.tar d
$ rm -r d
$ tar xf d.tar
$ ls -ld d d/file
drwxr-xr-x 2 guru wheel 512 30 abr. 01:01 d
-rw-r--r-- 1 guru wheel 0 30 abr. 01:01 d/file


I will investigate, why it didn't went this way with my restore.

Btw:

$ uname -a
FreeBSD c720-1400094 14.0-CURRENT FreeBSD 14.0-CURRENT amd64 1400094 #2 main-n264568-1d7ffb373c9d-dirty: Wed Sep 6 07:13:22 CEST 2023 guru@jet:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

[Matthias Apitz]

I can reproduce the problem with:

$ rm -r d
$ mkdir d
$ touch -t 202504300101 d/file d
$ ls -ld d d/file
drwxr-xr-x 2 guru wheel 512 30 abr. 01:01 d
-rw-r--r-- 1 guru wheel 0 30 abr. 01:01 d/file
$ tar cf d.tar d

(without deleting the directory 'd')

$ tar xf d.tar
$ ls -ld d d/file

drwxr-xr-x 2 guru wheel 512 1 may. 20:25 d

-rw-r--r-- 1 guru wheel 0 30 abr. 01:01 d/file

i.e. if the directories are existing (as it was in my original case
restoring into my HOME a backup), the modification time of the directory
will not be adjusted to the value in the tar archive. One could call
this a bug or a feature. Don't know.

[Jin Guojun[VFF]]

On 5/1/25 11:33, Matthias Apitz wrote:
> I can reproduce the problem with:
>
> $ rm -r d
> $ mkdir d
> $ touch -t 202504300101 d/file d
> $ ls -ld d d/file
> drwxr-xr-x 2 guru wheel 512 30 abr. 01:01 d
> -rw-r--r-- 1 guru wheel 0 30 abr. 01:01 d/file
> $ tar cf d.tar d
>
> (without deleting the directory 'd')
>
> $ tar xf d.tar
> $ ls -ld d d/file
> drwxr-xr-x 2 guru wheel 512 1 may. 20:25 d
> -rw-r--r-- 1 guru wheel 0 30 abr. 01:01 d/file
>
> i.e. if the directories are existing (as it was in my original case
> restoring into my HOME a backup), the modification time of the directory
> will not be adjusted to the value in the tar archive. One could call
> this a bug or a feature. Don't know.
>
> matthias

This is the original "tar" behavior, which does not restore the existing
directory timestamp.

The "mv" command actually gradually changed behavior on restoring
timestamp since 12-R, if my memory services correct.

11-R and earlier releases, mv directories to any other location, the
directory timestamp is intact. "mv" in some 12-R does and some does not.

In 13 and later releases, mv only restores the directory timestamp when
mv made cross file systems; it moving is made within the same file
system, the timestamp of the root directory is set to the moving
date-time, which is kind annoying.

-Jin

[Matthias Apitz]

El día jueves, mayo 01, 2025 a las 11:58:42a. m. -0700, Jin Guojun[VFF] escribió:

> On 5/1/25 11:33, Matthias Apitz wrote:
> > I can reproduce the problem with:
> >
> > $ rm -r d
> > $ mkdir d
> > $ touch -t 202504300101 d/file d
> > $ ls -ld d d/file
> > drwxr-xr-x 2 guru wheel 512 30 abr. 01:01 d
> > -rw-r--r-- 1 guru wheel 0 30 abr. 01:01 d/file
> > $ tar cf d.tar d
> >
> > (without deleting the directory 'd')
> >
> > $ tar xf d.tar
> > $ ls -ld d d/file
> > drwxr-xr-x 2 guru wheel 512 1 may. 20:25 d
> > -rw-r--r-- 1 guru wheel 0 30 abr. 01:01 d/file
> >
> > i.e. if the directories are existing (as it was in my original case
> > restoring into my HOME a backup), the modification time of the directory
> > will not be adjusted to the value in the tar archive. One could call
> > this a bug or a feature. Don't know.
> >
> > matthias
>
> This is the original "tar" behavior, which does not restore the existing
> directory timestamp.
>
> The "mv" command actually gradually changed behavior on restoring timestamp
> since 12-R, if my memory services correct.
>

> ...

I will repair this problem im my HOME partition. From the tar-listing I
grep'ed out all directory lines (having a '/' at the end):

drwxr-xr-x 0 guru wheel 0 1 Mai 08:15 guru/
drwx------ 0 guru wheel 0 10 Apr. 21:48 guru/.ssh/
drwxr-xr-x 0 guru wheel 0 1 Mai 07:40 guru/.config/
drwxr-xr-x 0 guru wheel 0 1 Mai 08:35 guru/.cache/
drwx------ 0 guru wheel 0 5 Dez. 2020 guru/.dbus/
drwxr-xr-x 0 guru wheel 0 5 Dez. 2020 guru/.kde/
... 22300 lines...

removed unnecessary data with vim, so the lines look like:

1 Mai 08:15 guru/
10 Apr. 21:48 guru/.ssh/
1 Mai 07:40 guru/.config/
1 Mai 08:35 guru/.cache/
5 Dez. 2020 guru/.dbus/
5 Dez. 2020 guru/.kde/
...

and wrote a shell script (attached) to generate touch-commands from the
data:

touch -t 202505010101 'guru/'
touch -t 202504100101 'guru/.ssh/'
touch -t 202505010101 'guru/.config/'
touch -t 202505010101 'guru/.cache/'
touch -t 202012050101 'guru/.dbus/'
touch -t 202012050101 'guru/.kde/'
...

[Daniel Tameling]

On Thu, May 01, 2025 at 05:04:12PM +0200, Matthias Apitz wrote:
>

Hi,

GNU tar has an option to deal with this:

--delay-directory-restore
Delay setting modification times and permissions of extracted
directories until the end of extraction. Use this option when
extracting from an archive which has unusual member ordering.

It is available as the gtar command if you install the gtar package.

--
Best regards,
Daniel