restore don't change ctime

Help
nickwen
2006-03-31
2013-05-20
  • nickwen

    nickwen - 2006-03-31

    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!

     
    • nickwen

      nickwen - 2006-03-31

      it runs on dump-0.4b41!
      it should change ctime to the previous state, but it failed!

       
    • nickwen

      nickwen - 2006-04-03

      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 ?

       
    • Stelian Pop

      Stelian Pop - 2006-04-03

      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."

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks