[
https://issues.apache.org/jira/browse/FLINK-6103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975260#comment-15975260
]
ASF GitHub Bot commented on FLINK-6103:
---------------------------------------
Github user StephanEwen commented on the issue:
https://github.com/apache/flink/pull/3598
I would do the following:
- log nothing
- Catch the errors that are regular "move failed" exceptions and return
false.
- `FileNotFoundException`
- `DirectoryNotEmptyException`
- `SecurityException`
- Let all other `IOExceptions` bubble out
> LocalFileSystem rename() uses File.renameTo()
> ---------------------------------------------
>
> Key: FLINK-6103
> URL: https://issues.apache.org/jira/browse/FLINK-6103
> Project: Flink
> Issue Type: Bug
> Components: Local Runtime
> Reporter: Flavio Pompermaier
> Assignee: Flavio Pompermaier
> Labels: filesystem
>
> I've tried to move a directory to another on the LocalFilesystem and it
> doesn't work (in my case fs is an instance of java.io.UnixFileSystem).
> As for Flink-1840 (there was a PR to fix the issue -
> https://github.com/apache/flink/pull/578) the problem is that
> {{File.renameTo()}} is not reliable.
> Indeed, the Javadoc says:
> bq. Renames the file denoted by this abstract pathname. Many aspects of the
> behavior of this method are inherently platform-dependent: The rename
> operation might not be able to move a file from one filesystem to another, it
> might not be atomic, and it might not succeed if a file with the destination
> abstract pathname already exists. The return value should always be checked
> to make sure that the rename operation was successful. Note that the
> java.nio.file.Files class defines the move method to move or rename a file in
> a platform independent manner
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
