System Administration
cancel
Showing results for 
Search instead for 
Did you mean: 

vrestore does not restore modification times

SOLVED
Go to solution
jamesD
Occasional Advisor

vrestore does not restore modification times

Hello All,

When I use vrestore to restore an entire file system, the file modification times for all files restored are not preserved. (modification times are set to the current time.) Am I correct in assuming that vdump/vrestore should be preserving file modification times? I am using the following commands to backup / restore.


vdump -0 -u -C -f /mnt/archive.vdump /to/be/dumped

vrestore -x -v -D /to/be/dumped -f /mnt/archive.vdump

Thanks for your time,

James
6 REPLIES
jamesD
Occasional Advisor

Re: vrestore does not restore modification times

Pardon me; I meant to say that modification times are not restored for directories. File times are correctly restored.

Thanks again,
James
Steven Schweda
Honored Contributor

Re: vrestore does not restore modification times

When you say that "the file modification
times for all files restored are not
preserved", do you mean that the times are
restored for none of the files, or that the
times are restored for only some of the
files? (And if only some, which?)

I can't easily check it now, but I'd expect
plain files to look the same as before. I
would not be amazed if _directories_ looked
new.
jamesD
Occasional Advisor

Re: vrestore does not restore modification times

I spoke imprecisely and prematurely. The situation is this:

After the restore:

All files have correct times.

Each restored directory has a modification time which is the time the directory was created by vrestore.


Can you elaborate on why you are not surprised to see directories look 'new?' Does vrestore not restore modification times for directories?

Thanks,
James
Steven Schweda
Honored Contributor
Solution

Re: vrestore does not restore modification times

> [...] I meant to say [...]

Ah. Anticipated again.

We just had this argument among the Info-ZIP
developers a while ago in regard to how UnZip
and Zip should work. The key concept is that
the destination directories are not being
_restored_, they're being _created_, so they
_should_ look new.

It's easier to see the reason for this in the
case where not all the files in a directory
are included in the saveset. Here, the
destination directory would differ from the
original directory (because it would have
fewer files in it), so clearly it shouldn't
have the same mod-date-time in that case.

In general, an archiving program (here,
vdump) stores info _about_ a directory, but
not the actual directory contents (which
might be different on a different file
system, too). Then, the program doing the
restoration (here, vrestore) can't know what
all was in the original directory, and it's
really creating files in the new directory
(on the destination file system, which could
be different), so it really does make sense
that the destination directories should
_look_ new (because they really _are_ new).

You may find an archiving program (like, say,
"tar", or some versions of UnZip) which will
set new destination directory date-times to
match those in the source, but it might be
lying when it does so.
jamesD
Occasional Advisor

Re: vrestore does not restore modification times

Sounds perfectly logical. Thank you for your help.
Steven Schweda
Honored Contributor

Re: vrestore does not restore modification times

> Sounds perfectly logical.

Not to everyone, I've found (hence that
argument I mentioned).

VMS BACKUP does the same thing usually, but
it also has a /IMAGE option, which ensures
that an entire file system (disk) is
archived, and I believe that a BACKUP /IMAGE
restoration _will_ restore the directory
date-time data. (No bets, but I believe that
that's true.)

Everything's complicated, I always say.