On Fri, Sep 23, 2022 at 4:09 AM Marc-André Lureau <marcandre.lur...@gmail.com> wrote: > > Hi > > On Tue, Sep 20, 2022 at 2:33 PM Bin Meng <bmeng...@gmail.com> wrote: >> >> From: Xuzhou Cheng <xuzhou.ch...@windriver.com> >> >> The combination of GENERIC_WRITE and FILE_SHARE_READ options does >> not allow the same file to be opened again by CreateFile() from >> another QEMU process with the same options when the previous QEMU >> process still holds the file handle opened. >> >> This was triggered by running the test_multifd_tcp_cancel() case on >> Windows, which cancels the migration, and launches another QEMU >> process to migrate with the same file opened for write. Chances are >> that the previous QEMU process does not quit before the new QEMU >> process runs hence the old one still holds the file handle that does >> not allow shared write permission then the new QEMU process will fail. >> >> As per [1] we should add FILE_SHARE_WRITE to the share mode to allow >> such use case. This change makes the behavior be consistent with the >> POSIX platforms. >> >> [1] >> https://docs.microsoft.com/en-us/windows/win32/fileio/creating-and-opening-files >> >> Signed-off-by: Xuzhou Cheng <xuzhou.ch...@windriver.com> >> Signed-off-by: Bin Meng <bin.m...@windriver.com> >> --- >> >> Changes in v2: >> - Update commit message to include the use case why we should set >> FILE_SHARE_WRITE when openning the file for win32 > > > As discussed in v1, I would rather leave that patch out of this series, since > the visible issue is solved differently elsewhere. > > Also, I disagree with the approach to make windows behaviour consistent with > posix here, since I consider the windows behaviour (exclusive write access) > superior. I would rather teach the posix implementation about exclusive write > access. >
Okay, will drop this patch in v3. Regards, Bin
