You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Doug Cutting (JIRA)" <ji...@apache.org> on 2006/04/18 01:15:17 UTC

[jira] Updated: (HADOOP-129) FileSystem should not name files with java.io.File

     [ http://issues.apache.org/jira/browse/HADOOP-129?page=all ]

Doug Cutting updated HADOOP-129:
--------------------------------

    Attachment: path.patch

Here's a patch that replaces uses of java.io.File in Hadoop's FileSystem and MapReduce API's with a new class named Path.  I left some existing File-based methods, now deprecated, sufficient for Nutch to run w/o alteration.  I'd like to remove the deprecated methods after the 0.2 release.

I believe that the only incompatible change is that dfs.data.dir and mapred.local.dir, when lists of directories, must now be comma-separated and may no longer be space-separated.  This is in order to make things work better on Windows.

I have tested this in standalone and pseudo-distributed operation on both Linux and Windows, with unit tests and with the Nutch crawler.

Barring objections, I will apply this tomorrow.

> FileSystem should not name files with java.io.File
> --------------------------------------------------
>
>          Key: HADOOP-129
>          URL: http://issues.apache.org/jira/browse/HADOOP-129
>      Project: Hadoop
>         Type: Improvement

>   Components: fs
>     Versions: 0.1.0, 0.1.1
>     Reporter: Doug Cutting
>      Fix For: 0.2
>  Attachments: path.patch
>
> In Hadoop's FileSystem API, files are currently named using java.io.File.  This is confusing, as many methods on that class are inappropriate to call on Hadoop paths.  For example, calling isDirectory(), exists(), etc. on a java.io.File is not the same as calling FileSystem.isDirectory() or FileSystem.exists() passing that same file.  Using java.io.File also makes correct operation on Windows difficult, since java.io.File operates differently on Windows in order to accomodate Windows path names.  For example, new File("/foo") is not absolute on Windows, and prints its path as "\\foo", which causes confusion.
> To fix this we could replace the uses of java.io.File in the FileSystem API with String, a new FileName class, or perhaps java.net.URI.  The advantage of URI is that it can also naturally include the namenode host and port.  The disadvantage is that URI does not support tree operations like getParent().
> This change will cause a lot of incompatibility.  Thus it should probably be made early in a development cycle in order to maximize the time for folks to adapt to it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira