[
https://issues.apache.org/jira/browse/HDDS-12844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17944658#comment-17944658
]
Ivan Andika commented on HDDS-12844:
------------------------------------
[~swamirishi] [~hemantk] Can I check whether this is a bug? Seems even with a
chain of renames, as long as it's renamed back to the original key, there
shouldn't be any RENAME entry?
> Fix wrong condition for RENAME diff
> -----------------------------------
>
> Key: HDDS-12844
> URL: https://issues.apache.org/jira/browse/HDDS-12844
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Ivan Andika
> Assignee: Ivan Andika
> Priority: Major
>
> When checking for RENAME diff, it will use the following check
> [https://github.com/apache/ozone/blob/c7117dcc1731a5f8a82fc6f06b99bda9cd6e01c0/hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/snapshot/SnapshotDiffManager.java#L1373]
> {code:java}
> if (!isObjectModified || !Arrays.equals(oldKeyName, newKeyName))
> {
> renameDiffs.add(codecRegistry.asRawData(
> SnapshotDiffReportOzone.getDiffReportEntry(RENAME, oldKey,
> newKey)));
> } {code}
> !isObjectModified || !Arrays.equals(oldKeyName, newKeyName) should be
> !isObjectModified && !Arrays.equals(oldKeyName, newKeyName) - with && instead
> of ||
> From what I understand, the repercussion would be that all keys will be a
> part of the snapdiff, even the ones that are not modified between the two
> snapshots.
> We need to test the behavior more deeply.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
