有没有办法将有效的和现有的Hadoop Path对象变成有用的Java File对象。 有没有这样做的好方法，还是我需要大手笔代码提交？ 更明显的方法不起作用，它似乎是一个普通的代码
void func(Path p) { if (p.isAbsolute()) { File f = new File(p.toURI()); } }这不起作用，因为Path :: toURI（）返回“hdfs”标识符，Java的文件（URI URI）构造器只能识别“文件”标识符。
有没有办法让路径和文件一起工作？
**
好的，一个特定的例子怎么样？
Path[] paths = DistributedCache.getLocalCacheFiles(job);分布式缓存应该提供文件的本地化副本，但它会返回一个路径。 我假设分布式缓存使文件的本地副本位于同一磁盘上。 考虑到这个有限的例子，其中hdfs有希望不在方程中，是否有一种方法可以将Path可靠地转换为文件？
**
Is there a way to change a valid and existing Hadoop Path object into a useful Java File object. Is there a nice way of doing this or do I need to bludgeon to code into submission? The more obvious approaches don't work, and it seems like it would be a common bit of code
void func(Path p) { if (p.isAbsolute()) { File f = new File(p.toURI()); } }This doesn't work because Path::toURI() returns the "hdfs" identifier and Java's File(URI uri) constructor only recognizes the "file" identifier.
Is there a way to get Path and File to work together?
**
Ok, how about a specific limited example.
Path[] paths = DistributedCache.getLocalCacheFiles(job);DistributedCache is supposed to provide a localized copy of a file, but it returns a Path. I assume that DistributedCache make a local copy of the file, where they are on the same disk. Given this limited example, where hdfs is hopefully not in the equation, is there a way for me to reliably convert a Path into a File?
**
最满意答案
不是我所知道的。
据我了解，Hadoop中的Path表示分布式文件系统中节点的标识符。 这是一个与java.io.File不同的抽象，它代表本地文件系统上的一个节点。 Path甚至不可能具有表现等效的File表示，因为基础模型是根本不同的。
因此缺乏翻译。 我认为你的断言File对象是“[more]有用的”，你想要这个类的一个对象以便使用现有的库方法吗？ 由于上述原因，这不会很好。 如果它是你自己的库，你可以重写它以使用Hadoop Paths干净地工作，然后将任何文件转换为Path对象（这个方向作用为Paths是文件的严格超集）。 如果它是第三方库，那么你运气不好; 该方法的作者没有考虑到分布式文件系统的影响，只写了该方法来处理普通的旧本地文件。
Not that I'm aware of.
To my understanding, a Path in Hadoop represents an identifier for a node in their distributed filesystem. This is a different abstraction from a java.io.File, which represents a node on the local filesystem. It's unlikely that a Path could even have a File representation that would behave equivalently, because the underlying models are fundamentally different.
Hence the lack of translation. I presume by your assertion that File objects are "[more] useful", you want an object of this class in order to use existing library methods? For the reasons above, this isn't going to work very well. If it's your own library, you could rewrite it to work cleanly with Hadoop Paths and then convert any Files into Path objects (this direction works as Paths are a strict superset of Files). If it's a third party library then you're out of luck; the authors of that method didn't take into account the effects of a distributed filesystem and only wrote that method to work on plain old local files.
更多推荐
发布评论