[
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)
