hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HADOOP-12550) NativeIO#renameTo on Windows cannot replace an existing file at the destination.
Date Wed, 04 Nov 2015 23:21:27 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-12550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Chris Nauroth updated HADOOP-12550:
-----------------------------------
    Attachment: HADOOP-12550.002.patch

Thank you, Ivan.  I'm uploading patch v002 with the comment that you requested.

bq. (noticed only one semantic difference when the target folder already exists and it's empty)

There had been a bug related to this a long time ago, but it wasn't at the native code layer.
 Instead, it was in {{RawLocalFileSystem}}.  There has been workaround code in {{RawLocalFileSystem}}
for a long time, so I think we're OK on this.

bq. Before you commit, would you be able to validate that existing Common/Hdfs/MR/Yarn tests
did not regress on Windows?

Yes, I definitely want to do this.  To anyone reviewing, please do not commit yet.  :-)

> NativeIO#renameTo on Windows cannot replace an existing file at the destination.
> --------------------------------------------------------------------------------
>
>                 Key: HADOOP-12550
>                 URL: https://issues.apache.org/jira/browse/HADOOP-12550
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: native
>         Environment: Windows
>            Reporter: Chris Nauroth
>            Assignee: Chris Nauroth
>         Attachments: HADOOP-12550.001.patch, HADOOP-12550.002.patch
>
>
> {{NativeIO#renameTo}} currently has different semantics on Linux vs. Windows if a file
already exists at the destination.  On Linux, it's a passthrough to the [rename|http://linux.die.net/man/2/rename]
syscall, which will replace an existing file at the destination.  On Windows, it's a passthrough
to [MoveFile|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365239%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396],
which cannot replace an existing file at the destination and instead triggers an error.  The
easiest way to observe this difference is to run the HDFS test {{TestRollingUpgrade#testRollback}}.
 This fails on Windows due to a block recovery after truncate trying to replace a block at
an existing destination path.  This issue proposes to use [MoveFileEx|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365240(v=vs.85).aspx]
on Windows with the {{MOVEFILE_REPLACE_EXISTING}} flag.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message