[
https://issues.apache.org/jira/browse/HADOOP-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17945642#comment-17945642
]
ASF GitHub Bot commented on HADOOP-19522:
-----------------------------------------
bhattmanish98 opened a new pull request, #7633:
URL: https://github.com/apache/hadoop/pull/7633
JIRA: https://issues.apache.org/jira/browse/HADOOP-19522
-----------------------------------------------------------------------
On the blob endpoint, since rename is not a direct operation but a
combination of two operations—copy and delete—in the case of directory rename,
we first rename all the blobs that have the source prefix and, at the end,
rename the source to the destination.
In the normal rename flow, renaming is not allowed if the destination
already exists. However, in the case of recovery, there is a possibility that
some files have already been renamed from the source to the destination. With
the recent change
([HADOOP-19474](https://issues.apache.org/jira/browse/HADOOP-19474) ABFS:
[FnsOverBlob] Listing Optimizations to avoid multiple iteration over list
response. - ASF JIRA), where we create a marker if the path is implicit, rename
recovery will fail at the end when it tries to rename the source to the
destination after renaming all the files.
To fix this, while renaming the source to the destination, if we encounter
an error indicating that the path already exists, we will suppress the error
and mark the rename recovery as successful.
> ABFS: [FnsOverBlob] Rename Recovery Should Succeed When Marker File Exists
> with Destination Directory
> -----------------------------------------------------------------------------------------------------
>
> Key: HADOOP-19522
> URL: https://issues.apache.org/jira/browse/HADOOP-19522
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/azure
> Affects Versions: 3.5.0, 3.4.1
> Reporter: Manish Bhatt
> Assignee: Manish Bhatt
> Priority: Blocker
> Labels: pull-request-available
>
> On the blob endpoint, since rename is not a direct operation but a
> combination of two operations—copy and delete—in the case of directory
> rename, we first rename all the blobs that have the source prefix and, at the
> end, rename the source to the destination.
> In the normal rename flow, renaming is not allowed if the destination already
> exists. However, in the case of recovery, there is a possibility that some
> files have already been renamed from the source to the destination. With the
> recent change ([HADOOP-19474] ABFS: [FnsOverBlob] Listing Optimizations to
> avoid multiple iteration over list response. - ASF JIRA), where we create a
> marker if the path is implicit, rename recovery will fail at the end when it
> tries to rename the source to the destination after renaming all the files.
> To fix this, while renaming the source to the destination, if we encounter an
> error indicating that the path already exists, we will suppress the error and
> mark the rename recovery as successful.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
