[
https://issues.apache.org/jira/browse/HDDS-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16927955#comment-16927955
]
Steve Loughran commented on HDDS-2112:
--------------------------------------
This is covered inL
https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/site/markdown/filesystem/filesystem.md#boolean-renamepath-src-path-d
basically
* rename is a confusing mess and the whole return true/false world complicates
life
* everything other than HDFS (including local) raises an FNFE when the parent
isn't there
* having rename() return false is generally useless for applications, which are
invariably full of code like
{code}
if (!rename(src, dest)) throw new IOE("rename failed and we don't know why!")
{code}
We have tests for what rename does in
inorg.apache.hadoop.fs.contract.AbstractContractRenameTest; if you want to see
the core quirks which rename() can get up to, look at
org.apache.hadoop.fs.contract.ContractOptions
Ultimately we need to get HADOOP-11452 in and make the rename/3 call public.
That's the one called via FileContext and which, for HDFS, does raise
exceptions in the two situations created.
closing as a WONTFIX as it is HDFS through the FileSystem.rename(src, dest) API
call which is considered the incorrect behaviour
Well done for finding this though -good bit of research!
> rename is behaving different compared with HDFS
> -----------------------------------------------
>
> Key: HDDS-2112
> URL: https://issues.apache.org/jira/browse/HDDS-2112
> Project: Hadoop Distributed Data Store
> Issue Type: Bug
> Components: Ozone Filesystem
> Reporter: Istvan Fajth
> Priority: Major
> Attachments: demonstrative_test.patch
>
>
> I am attaching a patch file, that introduces two new tests for the
> OzoneFileSystem implementation which demonstrates the expected behaviour.
> Case 1:
> Given a directory a file "/source/subdir/file", and a directory /target
> When fs.rename("/source/subdir/file", "/target/subdir/file") is called
> Then DistributedFileSystem (HDFS), is returning false from the method, while
> OzoneFileSystem throws a FileNotFoundException as "/target/subdir" is not
> existing.
> The expected behaviour would be to return false in this case instead of
> throwing an exception with that behave the same as DistributedFileSystem does.
>
> Case 2:
> Given a directory "/source" and a file "/targetFile"
> When fs.rename("/source", "/targetFile") is called
> Then DistributedFileSystem (HDFS), is returning false from the method, while
> OzoneFileSystem throws a FileAlreadyExistsException as "/targetFile" does
> exist.
> The expected behaviour would be to return false in this case instead of
> throwing an exception with that behave the same as DistributedFileSystem does.
>
> It may be considered as well a bug in HDFS, however it is not clear from the
> FileSystem interface's documentation on the two rename methods that it
> defines in which cases an exception should be thrown and in which cases a
> return false is the expected behaviour.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
