update switch bug

ccaid
2017-01-09
6 days ago
  • ccaid

    ccaid - 2017-01-09

    in some specific conditions 7-Zip do not put folder's time stamp into delta archive (produced by -up0q3x2z0!delta.7z switch). so if the delta archive will be unpacked, folder's date&time will not be restored.
    bug's demo (touch util needed):
    ---8<-------------------------------------
    md aaa
    cd aaa

    rem file creation
    md bbb
    echo text1 >bbb\f.txt
    touch -d 2015-01-10 bbb\f.txt
    touch -d 2015-01-10 bbb

    rem backup 1
    7z u ..\test.7z -up0q3x2z0!..\test1.7z *

    rem file substitution (new content, new size, same date)
    echo text12 >bbb\f.txt
    touch -d 2015-01-10 bbb\f.txt
    touch -d 2015-01-10 bbb

    rem backup 2
    7z u ..\test.7z -up0q3x2z0!..\test2.7z *
    ---8<-------------------------------------
    test2.7z does not contain "bbb" folder's time stamp.

    test env:
    7z.exe v16.04 x32
    Win 8.1 x32 / Win 10 x64
    NTFS

     
  • Igor Pavlov

    Igor Pavlov - 2017-01-09

    in some specific conditions 7-Zip do not put folder's time stamp into delta archive (produced by -up0q3x2z0!delta.7z switch).

    If folders timestamps are identical, it doesn't store item to delta archive.
    And If there is no folder item, then there is no timestamp for that item.

    so if the delta archive will be unpacked, folder's date&time will not be restored.

    So the problem that if you extract delta archive, and there is no directory item in delta archive, it will change timestamp of folder to current time, if it extracts some file to that folder.

    Now I'm not ready to solve that problem case.

    Do you have any real case of that problem, without these "artificial" touch instructions?

     
    • ccaid

      ccaid - 2017-01-09

      If folders timestamps are identical, it doesn't store item to delta archive.

      a necessary condition but not sufficient.
      folder's timestamp also depends on files and folders below. so if any of they was changed, it will changed too, and shall be restored.

      Do you have any real case of that problem, without these "artificial" touch instructions?

      the real case really uses touch command.
      each file comprises some kind of attributes and content inside it. content never changed (if changed, it will be new file), but attributes may be changed from time to time. file's timestamp so becomes random value. for convenience and easy synchronizing of several copies of files sets each file's timestamp changed to the file creation time by touch command. file creation time featched from database.

       
  • Igor Pavlov

    Igor Pavlov - 2017-01-10

    Please write simpler.
    Why do you change real timestamps for files?
    Why do you change real timestamps for folders?

    Do you have problems in delta archives only for folders timestamps?

     
    • ccaid

      ccaid - 2017-01-10

      Why do you change real timestamps for files?
      Why do you change real timestamps for folders?

      1) 'couse I use 7z delta archives to synchronize several copies of set of files. if timestamps of files and especially folders are random, this leads to wrong/false triggering of 7z delta creation.
      2) bonus: each timestamp bears creation time of file not as file system object but as content object.

      Do you have problems in delta archives only for folders timestamps?

      yes.

       
  • Igor Pavlov

    Igor Pavlov - 2017-01-11

    if timestamps of files and especially folders are random

    Timestamps show real time of last writing.
    So it's objective information, not random.

     
    • ccaid

      ccaid - 7 days ago

      true random generators have fully objective output too :)
      files are fetched from database. fetches made at diffrent computers or at diffrent time moments have diffrent timestamps. so this timestamps are random at some sence.

       

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks