[ https://issues.apache.org/jira/browse/ARROW-3936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17660960#comment-17660960 ]
Rok Mihevc commented on ARROW-3936: ----------------------------------- This issue has been migrated to [issue #20544|https://github.com/apache/arrow/issues/20544] on GitHub. Please see the [migration documentation|https://github.com/apache/arrow/issues/14542] for further details. > Add _O_NOINHERIT to the file open flags on Windows > -------------------------------------------------- > > Key: ARROW-3936 > URL: https://issues.apache.org/jira/browse/ARROW-3936 > Project: Apache Arrow > Issue Type: Bug > Components: C++ > Reporter: Philip Felton > Priority: Major > Labels: pull-request-available > Fix For: 0.12.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Unlike Linux, Windows doesn't let you delete files that are currently opened > by another process. So if you create a child process while a Parquet file is > open, with the current code the file handle is inherited to the child > process, and the parent process can't then delete the file after closing it > without the child process terminating first. > By default, Win32 file handles are not inheritable (likely because of the > aforementioned problems). Except for _wsopen_s, which tries to maintain POSIX > compatibility. > This is a serious problem for us. > We would argue that specifying _O_NOINHERIT by default in the _MSC_VER path > is a sensible approach and would likely be the correct behaviour as it > matches the main Win32 API. > However, it could be that some developers rely on the current inheritable > behaviour. In which case, the Arrow public API should take a boolean argument > on whether the created file descriptor should be inheritable. But this would > break API backward compatibility (unless a new overloaded method is > introduced). > Is forking and inheriting Arrow internal file descriptor something that Arrow > actually means to support? > See [https://github.com/apache/arrow/pull/3085.] What do we think of the > proposed fix? -- This message was sent by Atlassian Jira (v8.20.10#820010)