You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Joseph Wu (JIRA)" <ji...@apache.org> on 2017/01/20 01:18:26 UTC

[jira] [Comment Edited] (MESOS-6707) Port `gc_tests.cpp`

    [ https://issues.apache.org/jira/browse/MESOS-6707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830967#comment-15830967 ] 

Joseph Wu edited comment on MESOS-6707 at 1/20/17 1:17 AM:
-----------------------------------------------------------

{code}
commit 5b52217f34197a459fffe3c09be9167046be9df6
Author: Alex Clemmer <cl...@gmail.com>
Date:   Wed Jan 18 14:53:38 2017 -0800

    Windows: Fixed hanging symlink bug in `os::rmdir`.
    
    The Windows implementation of `os::rmdir` will fail to delete "hanging"
    symlinks (i.e., symlinks whose targets do not exist). Note that on
    Windows this bug is specific to symlinks whose targets are _deleted_,
    since it is impossible to create a symlink whose target does not exist.
    
    The primary issue that causes this problem is that it is very difficult
    to tell whether a symlink points at a directory or a file unless you
    resolve the symlink and determine whether the target is a directory or a
    file. In situations where the target does not exist, we can't use this
    information, and so `os::rmdir` occasionally mis-routes a symlink to
    (what was) a directory to a `::remove` call, which will fail with a
    cryptic error.
    
    To fix this behavior, this commit will introduce code that simply tries
    to remove the reparse point with both `RemoveDirectory` and
    `DeleteFile`, and if either succeeds, we report success for the
    operation. This represents a "best effort"; in the case that the reparse
    point represents something more exotic than a symlink, we will still
    fail, but by choosing not to verify whether the target is a directory or
    a file, we simplify the code and still obtain the outcome of having
    deleted the directory.
    
    This commit is the primary blocker for MESOS-6707, as deleting the Agent
    sandbox will sometimes cause us to delete the latest run directory for
    the executor before the symlinked `latest` directory itself. This causes
    the delete to fail, and then the GC tests to fail, since they tend to
    assert the directory does not exist.
    
    Review: https://reviews.apache.org/r/55327/
{code}
{code}
commit 08e5cd2580a142977b2d8a3abf2a70a398147f01
Author: Alex Clemmer <cl...@gmail.com>
Date:   Wed Jan 18 14:59:17 2017 -0800

    Windows: Added GC tests to the build.
    
    These tests are fixed by the fix to `os::rmdir` in review #55327.
    The tests were failing to delete sandbox folders when the sandbox
    was deleted before deleting the symlink to the sandbox.
    
    Review: https://reviews.apache.org/r/55328/
{code}


was (Author: kaysoky):
{code}
commit 08e5cd2580a142977b2d8a3abf2a70a398147f01
Author: Alex Clemmer <cl...@gmail.com>
Date:   Wed Jan 18 14:59:17 2017 -0800

    Windows: Added GC tests to the build.
    
    These tests are fixed by the fix to `os::rmdir` in review #55327.
    The tests were failing to delete sandbox folders when the sandbox
    was deleted before deleting the symlink to the sandbox.
    
    Review: https://reviews.apache.org/r/55328/
{code}

> Port `gc_tests.cpp`
> -------------------
>
>                 Key: MESOS-6707
>                 URL: https://issues.apache.org/jira/browse/MESOS-6707
>             Project: Mesos
>          Issue Type: Bug
>          Components: agent
>            Reporter: Alex Clemmer
>            Assignee: Alex Clemmer
>              Labels: microsoft, windows-mvp
>             Fix For: 1.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)