utimes does not change ctime. There is no UNIX syscall to change ctime. Restore accesses the filesystem through the standard syscalls, so it has no way to reset the ctime to the original one.
As for why you should not dump again a freshly restored filesystem read the manpage:
" A level 0 dump must be done after a full restore. Because restore runs
in user code, it has no control over inode allocation; thus a full dump
must be done to get a new set of directories reflecting the new inode
numbering, even though the content of the files is unchanged."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
firstly i do a full level dump
dump -u0 -b 60 -B 2000000 -M -f /root/stdev /dev/hda1
then i mkfs.ext3 /dev/hda1
mount /dev/hda1 /mnt/syspart
cd /mnt/syspart
restore -b 60 -M -r -f /root/stdev
after the filesystem successfully restored
i found the ctime is changed !
then if i do a level 2 dump
the dump search more files then expected!
it runs on dump-0.4b41!
it should change ctime to the previous state, but it failed!
i checked what ctime is, ctime is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.).
i also find utimes in tape.c
it is strange that ctime is changed when restored, why dump use ctime keywords to check the changes of the file, is it mtime not enough ?
utimes does not change ctime. There is no UNIX syscall to change ctime. Restore accesses the filesystem through the standard syscalls, so it has no way to reset the ctime to the original one.
As for why you should not dump again a freshly restored filesystem read the manpage:
" A level 0 dump must be done after a full restore. Because restore runs
in user code, it has no control over inode allocation; thus a full dump
must be done to get a new set of directories reflecting the new inode
numbering, even though the content of the files is unchanged."