Re: [PATCH v2 25/39] chardev/char-file: Add FILE_SHARE_WRITE when openning the file for win32

[Bin Meng]

On Fri, Sep 23, 2022 at 4:09 AM Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
>
> Hi
>
> On Tue, Sep 20, 2022 at 2:33 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 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.cheng@windriver.com>
>> Signed-off-by: Bin Meng <bin.meng@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