dombizita commented on code in PR #4478:
URL: https://github.com/apache/ozone/pull/4478#discussion_r1156003371
##########
hadoop-ozone/ozonefs-common/src/main/java/org/apache/hadoop/fs/ozone/BasicRootedOzoneFileSystem.java:
##########
@@ -430,8 +430,14 @@ private boolean renameFSO(OzoneBucket bucket,
// construct src and dst key paths
String srcKeyPath = srcPath.getNonKeyPathNoPrefixDelim() +
OZONE_URI_DELIMITER + srcPath.getKeyName();
- String dstKeyPath = dstPath.getNonKeyPathNoPrefixDelim() +
- OZONE_URI_DELIMITER + dstPath.getKeyName();
+ String dstKeyPath;
+ if (dstPath.isBucket()) {
+ dstKeyPath = dstPath.getNonKeyPathNoPrefixDelim() +
+ OZONE_URI_DELIMITER + srcPath.getFileName();
+ } else {
+ dstKeyPath = dstPath.getNonKeyPathNoPrefixDelim() +
+ OZONE_URI_DELIMITER + dstPath.getKeyName();
Review Comment:
> For OMKeyRenamRequest, we should not allow empty key name, that part is
ok. Only for OMKeyRenameRequestWithFSO, can remove toKeyName.length() == 0
check, and any further check if causing issue.
@sumitagrawl why do you think that we should differentiate the way we handle
FSO and non FSO buckets during the rename of a key/directory?
> I am proposing to fix at OM layer, because other client integration do not
need any change when passing source and destination, and OM layer should
support api with this behaviour.
I don't think so, the rename in case of a non FSO bucket is also doing the
necessary changes in the destination path (in both implementations in
`BasicOzoneFilesystem` and `BasicRootedOzoneFilesystem`). I believe it wasn't
intentional that in case of a non FSO bucket we didn't do the change.
as a conclusion, I'd like to avoid to remove the key name check from the
`OMKeyRenameRequestWithFSO` as it would cause inconsistency (with
`OMKeyRenameRequest`), which is not necessary in this case and it can be
confusing. let me know what you think of it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
