On Thu, Aug 25, 2022 at 3:59 PM Marc-André Lureau <marcandre.lur...@redhat.com> wrote: > > Hi > > On Wed, Aug 24, 2022 at 1:43 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 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.ch...@windriver.com> > > Signed-off-by: Bin Meng <bin.m...@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. > To me, it's the other way around, the POSIX implementation should > learn to lock the file opened for write.. > Regards, Bin
