[ http://issues.apache.org/jira/browse/HADOOP-129?page=all ]
Doug Cutting resolved HADOOP-129:
---------------------------------
Resolution: Fixed
Assign To: Doug Cutting
I just committed this. It was a big change. I hope I haven't broken anything!
> 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
> Assignee: 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
