On Thu, Aug 25, 2022 at 3:59 PM Marc-André Lureau
<marcandre.lureau@redhat.com> wrote:
>
> Hi
>
> On Wed, Aug 24, 2022 at 1:43 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > From: Xuzhou Cheng <xuzhou.cheng@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 openned.
>
> opened
>
> >
> > As per [1] we should add FILE_SHARE_WRITE to the share mode to allow
> > such use case. This change makes the behavior be consisten with the
> > POSIX platforms.
> >
>
> consistent
>
> > [1] https://docs.microsoft.com/en-us/windows/win32/fileio/creating-and-opening-files
> >
> > Signed-off-by: Xuzhou Cheng <xuzhou.cheng@windriver.com>
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > ---
>
>
> What's the benefit to allow multiple processes write access to the
> same file? It seems it could easily lead to corruption or unexpected
> results.
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 new one still holds the file handle that does
not allow shared write permission then the new QEMU process will fail.
Thanks for the details, that's worth to add in commit message imho.
But can't we fix the test instead to use different paths?
--