Re: [Sbcl-devel] open_binary() implementation

[Matthew S. <mts...@gm...>]

The attached patch does just that: open_binary() is now open_core()
and no longer has the mode argument. On windows, the core file is
opened with CreateFile and FILE_SHARE_DELETE is set. This version goes
to some trouble to make sure that errno is set correctly for error
reporting purposes.

Note that this patch doesn't quite allow deleting of dumped images,
due to the way that the windows loader maps executables into memory
(it does allow renaming, though).

Suggestions welcome.

-Matt Stickney

On Wed, Jun 28, 2017 at 4:30 PM, Matthew Stickney <mts...@gm...> wrote:
> I wanted to allow SBCL executables and core files to support
> linux-style unlink-while-open behavior on Windows (as it is, you can't
> rename or delete a dumped exe or core file while an SBCL program is
> running).
>
> The main issue is that open_binary() in src/runtime/coreparse.c uses
> open() on Windows, and the Windows implementation of open() doesn't
> set the FILE_SHARE_DELETE attribute when calling CreateFile()
> internally. Creating a POSIX-compliant wrapper around CreateFile()
> seems intractable.
>
> Given that open_binary() appears to only be used to open core files
> (or the current image), and is only used with O_RDONLY, would it be
> reasonable to change the name (e.g. to open_core()) and have the
> windows implementation use CreateFile() directly? If so, would the
> lack of an errno value be a problem (as far as I can tell, only the
> return value is checked)?
>
> I'm a little nervous making changes to the core runtime, although this
> isn't especially invasive. If somebody has a better idea[1], I'd be
> happy to hear it.
>
> -Matt Stickney
>
> [1] Windows has the sopen() function, which acts like open() and takes
> an additional sharing mode parameter, but it only allows DOS-style
> control bits, which don't include FILE_SHARE_DELETE.