hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9527) TestLocalFSFileContextSymlink is broken on Windows
Date Wed, 08 May 2013 05:19:15 GMT

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

Chris Nauroth commented on HADOOP-9527:
---------------------------------------

I expect you don't need to add {{assumeTrue(!Shell.WINDOWS)}} to {{FileContextSymlinkBaseTest}}
for the following methods: {{testCreateDanglingLink}}, {{testCreateFileViaDanglingLinkParent}},
{{testStatDanglingLink}}, {{testRecursiveLinks}}, and {{testRenameDirToDanglingSymlink}}.
 These were addressed in HADOOP-9043 by overriding the methods in {{TestLocalFSFileContextSymlink}}
and checking for Windows there.  It looks like I missed {{testRenameFileWithDestParentSymlink}}
though, so thanks for picking that one up.  Could you please follow the same strategy of overriding
it in {{TestLocalFSFileContextSymlink}}?

The reason for doing it this way is that by overriding it in the base class, we would skip
the test even in the case of HDFS on Windows ({{TestFcHdfsSymlink}}).  It's only the combination
of Windows and local file system that doesn't support dangling symlinks, so by overriding
it in the subclass, we only skip the test in that very specific case.

{code}
+   * Returns the target of the given symlink. Returns the empty string if
+   * the given path does not refer to a symlink or there is an error
+   * acessing the symlink.
{code}
Minor nit: misspelling of accessing.

{code}
    RawLocalFileStatus(File f, long defaultBlockSize, FileSystem fs) {
      super(
          RawLocalFileSystem.getFileLength(f),
          f.isDirectory(),
          1,
          defaultBlockSize,
          f.lastModified(),
          0,
          null,
          null,
          null,
          null,
          new Path(f.getPath()).makeQualified(fs.getUri(),
            fs.getWorkingDirectory()));
    }
{code}

Was this change intended only for formatting, or was it intentional to switch to calling a
different superclass constructor?  I think we could potentially remove the arguments 0, null,
null, null, null, because even if you omit them, the base class constructors will chain to
do the same thing.

                
> TestLocalFSFileContextSymlink is broken on Windows
> --------------------------------------------------
>
>                 Key: HADOOP-9527
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9527
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: test
>    Affects Versions: 3.0.0
>            Reporter: Arpit Agarwal
>            Assignee: Arpit Agarwal
>             Fix For: 3.0.0
>
>         Attachments: HADOOP-9527.001.patch, HADOOP-9527.002.patch, HADOOP-9527.003.patch,
HADOOP-9527.004.patch, RenameLink.java
>
>
> Multiple test cases are broken. I didn't look at each failure in detail.
> The main cause of the failures appears to be that RawLocalFS.readLink() does not work
on Windows. We need "winutils readlink" to fix the test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message