Skip to main content

Public

Project privacy set to public. By default, its content is available to everyone (authenticated or not). Please note that more restrictive permissions might exist on some items.

    •  
      request #8098 Restoration of deleted git repository failed
    Actions
    Infos
    #8098
    Manuel Vacelet (vaceletm)
    2015-05-28 17:21
    2015-05-26 17:26
    8122
    Details
    Restoration of deleted git repository failed

    During 8.2 valid on c6

    11023 SystemEvent_GIT_REPO_RESTORE app ERROR 2
2015-05-26 15:16:24 2015-05-26 15:17:01 2015-05-26 15:17:02 Unable to restore repository : arch/i386

    What is strange is that there are no parameters

     

    SCM/Git
    development
    CentOS 6
    • [ ] enhancement
    • [ ] internal improvement
    Empty
    Stage
    Yannis ROSSETTO (rossettoy)
    Closed
    2015-05-28
    Attachments
    Artifact links
    Empty
    Empty
    References
    Referencing request #8098

    Artifact Tracker v5

    rel #8037 8.2
    rel #8112 8.3

    Git commit

    tuleap/tuleap/stable

    Merge commit 'refs/changes/13/4013/1' of ssh://gerrit.tuleap.net:29418/tuleap into tuleap-stable-master 0ef7746c12
    User avatar Manuel Vacelet (vaceletm) , 2015-05-27 09:25
    request #8098 Restoration of deleted git repository failed 8ee3f3d41e
    User avatar Yannis ROSSETTO (rossettoy) , 2015-05-27 09:02
    Merge commit 'refs/changes/20/4020/1' of ssh://gerrit.tuleap.net:29418/tuleap into HEAD 0b9c367a4a
    User avatar Yannis ROSSETTO (rossettoy) , 2015-05-28 15:24
    request #8098 Restoration of deleted git repository failed 9e62890764
    User avatar Manuel Vacelet (vaceletm) , 2015-05-28 14:43
    Referenced by request #8098

    Other

    gerrit #4013
    gerrit #4020
    Display settings

    Follow-ups

    User avatar
    Yannis ROSSETTO (rossettoy)2015-05-28 14:50
    I tested with this patch and with a 640 mode, my event failed. Then, with 644 mode, the event is OK and the repository is restored with the content.
    User avatar
    Manuel Vacelet (vaceletm)2015-05-28 14:07
    Hi

    > It's normal that restore fail, I already mentionned in request#8077 that removing "term=XTERM" will create this regression

    As already said, setting term only prevent a message to be displayed. This message is not at all an error and you can actually verify by yourself that the git repository is actually restored on the file system. However, as the code rely on the fact that there is no output to decide whether the untar succeeded, the restoration process stops because it believe that something wrong happened.

    However, you are right that changing the backuped repo to 0640 will fail.
    The reason is that System_Command will only throw an exception if the exit code of the executed command is different of 0 (zero). The only true way to decide whether something is success or not in Unix/Posix world.

    So the right way to fix it is to make restore-tar command return the actual exit code of tar instead of relying on command output.
    User avatar
    Mohamed Amin Doghri (doghrim)2015-05-28 13:45
    Hi ,

    It's normal that restore fail, I already mentionned in request#8077 that removing "term=XTERM" will create this regression.
    Besides, the use of "try catch" doesn't throw any error.
    For instance if you set the mod of backuped repo to 640 and you try to restore, you should get a permission denied error, but with try-catch you will now get a green sys event with no error in git syslog and the restored will be empty.

    I already tried the use of try catch before submitting my patch set (gerrit#3961) and I retested now, thus I can confirm that "try catch" don't throw any error.

    Could you please check if the use of "try catch" in gerrit #4013 throw errros ?

    Thanks
    • Status changed from Closed to Reopen
    • Close date cleared
    User avatar
    Manuel Vacelet (vaceletm)2015-05-27 09:26
    • Status changed from Under review to Closed
    • Assigned to changed from None to Yannis ROSSETTO (rossettoy)
    • Close date set to 2015-05-27
    User avatar
    Yannis ROSSETTO (rossettoy)2015-05-26 20:02
    We found the root cause: The error verification does not rely on command status code, but on message returned.

    As this warning is returned, the event transforms this as an error, which is wrong. We will provide a fix for that.