hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9761) ViewFileSystem#rename fails when using DistributedFileSystem
Date Thu, 01 Aug 2013 01:24:46 GMT

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

Colin Patrick McCabe commented on HADOOP-9761:
----------------------------------------------

Yeah, you're absolutely right.  There is a difference between {{FileSystemLinkResolver}},
where you have this code in {{FileSystemLinkResolver#resolve}}:

{code}
        // Have to call next if it's a new FS
        if (!fs.equals(filesys)) {
          return next(fs, p);
        }
{code}

and {{FSLinkResolver#resolve}}, where you have this code:
{code}
    // Loop until all symlinks are resolved or the limit is reached
    for (boolean isLink = true; isLink;) {
      try {
        in = next(fs, p);
        isLink = false;
      ...
{code}

In other words, FSLinkResolver doesn't have {{doCall}}, only {{next}}.

bq. So, I think this means the #doCall here should always fail the FileSystem#checkPath check.

I think it's better to just raise an exception directly, than to rely on another method to
do it.  There's less coupling in the code and it's clearer.  Maybe something like this?
{code}
         public Void next(final FileSystem fs, final Path p)
             throws IOException {
           throw new IllegalArgumentException("Wrong FS: "+path+
                                       ", expected: "+ fileSys.getUri());
         }
{code}

I think this makes it a lot more obvious what's going on... what do you think
                
> ViewFileSystem#rename fails when using DistributedFileSystem
> ------------------------------------------------------------
>
>                 Key: HADOOP-9761
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9761
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: viewfs
>    Affects Versions: 3.0.0, 2.1.0-beta
>            Reporter: Andrew Wang
>            Assignee: Andrew Wang
>         Attachments: 0001-HADOOP-9761.004.patch, hadoop-9761-1.patch, hadoop-9761-1.patch,
hadoop-9761-2.patch
>
>
> ViewFileSystem currently passes unqualified paths (no scheme or authority) to underlying
FileSystems when doing a rename. DistributedFileSystem symlink support added in HADOOP-9418
needs to qualify and check rename sources and destinations since cross-filesystem renames
aren't supported, so this breaks in the following way
> - Default FS URI is configured to viewfs://<viewfs>
> - When doing a rename, ViewFileSystem checks to make sure both src and dst FileSystems
are the same (which they are, both in same DFS), and then calls DistributedFileSystem#rename
with unqualified "remainder" paths
> - Since these paths are unqualified, DFS qualifies them with the default FS to check
that it can do the rename. This turns it into viewfs://<viewfs>/<path>
> - Since viewfs://<viewfs> is not the DFS's URI, DFS errors out the rename.

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