[
https://issues.apache.org/jira/browse/HDFS-7878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16140008#comment-16140008
]
Steve Loughran commented on HDFS-7878:
--------------------------------------
# FS APIs? Pull in [~sanjay.radia]
# There's now a builder API for open/create, that's the only one that should be
added for a path handle
# similarly, the full rename with opts, none of the other "utility" renames;
the list calls should always return an RemoteIterator. That is, the "better"
calls.
# though there, I'm a bit confused as to what a PathHandle to an as yet
uncreated path would be?
#
Overall, and I think Sanjay will be aligned with me here, doing this in
FileContext would be better. I know I've been doing things underneath
FileSystem, but that doesn't mean we should do more in terms of evolving that
API.
> API - expose an unique file identifier
> --------------------------------------
>
> Key: HDFS-7878
> URL: https://issues.apache.org/jira/browse/HDFS-7878
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Labels: BB2015-05-TBR
> Attachments: HDFS-7878.01.patch, HDFS-7878.02.patch,
> HDFS-7878.03.patch, HDFS-7878.04.patch, HDFS-7878.05.patch,
> HDFS-7878.06.patch, HDFS-7878.patch
>
>
> See HDFS-487.
> Even though that is resolved as duplicate, the ID is actually not exposed by
> the JIRA it supposedly duplicates.
> INode ID for the file should be easy to expose; alternatively ID could be
> derived from block IDs, to account for appends...
> This is useful e.g. for cache key by file, to make sure cache stays correct
> when file is overwritten.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
