[
https://issues.apache.org/jira/browse/FLINK-6103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15940053#comment-15940053
]
ASF GitHub Bot commented on FLINK-6103:
---------------------------------------
Github user StephanEwen commented on a diff in the pull request:
https://github.com/apache/flink/pull/3598#discussion_r107863788
--- Diff:
flink-core/src/main/java/org/apache/flink/core/fs/local/LocalFileSystem.java ---
@@ -262,8 +265,13 @@ public FSDataOutputStream create(
public boolean rename(final Path src, final Path dst) throws
IOException {
final File srcFile = pathToFile(src);
final File dstFile = pathToFile(dst);
-
- return srcFile.renameTo(dstFile);
+ //Files.move fails if the destination directory doesn't exist
+ if(dstFile.getParentFile()!= null &&
!dstFile.getParentFile().exists()){
+
Files.createDirectories(dstFile.getParentFile().toPath());
+ }
+ //this throws an IOException if any error occurs
+ Files.move(srcFile.toPath(), dstFile.toPath(),
StandardCopyOption.REPLACE_EXISTING);
--- End diff --
If we want to preserve the old semantics, we should catch the exception and
return `false` in that case.
> 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)
