Better FileContext getFSoPath comment
-------------------------------------
Key: HADOOP-6442
URL: https://issues.apache.org/jira/browse/HADOOP-6442
Project: Hadoop Common
Issue Type: Bug
Reporter: Eli Collins
The getFSofPath method in FileContext returns a subclass of AbstractFileSystem
that matches the scheme of the given path (eg maps "hdfs" -> class Hdfs).
However the "file" scheme (eg "file:///xxx") maps to multiple classes:
{noformat}
AbstractFileSystem
-> DelegateToFileSystem -> RawLocalFs
-> RawLocalFileSystem
-> FilterFs -> ChecksumFs -> LocalFs
{noformat}
eg "file:/f" may have been created using RawLocalFileSystem but getFSofPath
returns an instance of LocalFs because core-default.xml maps
"fs.AbstractFileSystem.*file*.impl" to "LocalFs". The current API can lead to
surprises, eg trying to delete (using FileContext) a file created using
RawLocalFs doesn't use the appropriate delete method because getFSoPath returns
a LocalFs and so the delete method in ChecksumFs is used. The latter doesn't
delete dangling symlinks like the former which is how I noticed. There could be
other bugs, eg looking for checksums for a file that wasn't created with
ChecksumFs. Is there any reason to not unify local file systems under a single
path in the class hierarchy? Either way we should doc this behavior in a
comment in getFSofPath.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
