Re: [PATCH] Fix tests under Windows

[elf]

Still trying to get licences to set up Windows test VMs. VPN already set up to 
accomodate remote desktop, once licences are received. Again, if anyone has any 
win10/server 2018+ licences that they're not using, please get ahold of me. To 
do this properly, I'll need at least 6 licences - and that's assuming we only 
want support for 64-bit win10/server 2018 and later. 

-elf

On 5 September 2021 15:12:49 GMT+03:00, Mario Domenech Goulart 
<mario@parenteses.org> wrote:
>Hi Peter,
>
>On Thu, 2 Sep 2021 10:26:00 +0200 Peter Bex <peter@more-magic.net> wrote:
>
>> As Vasilij already reported, there are two failing tests under mingw.
>> They initially fail for the same reason - they try to delete files
>> that have been opened but not closed, which is an error under Windows.
>>
>> After fixing this, the posix-tests fail due to the fact that Windows
>> doesn't fully support file modes.  It doesn't know about execute
>> permissions, and doesn't support making files write-only or having
>> files with no permissions.
>>
>> To fix that, we can conceptually "right-extend" the user permissions
>> over group and others after adding read permissions (as Windows does
>> not have files without read permissions) and dropping execute
>> permissions.  In code, I cond-expand on Windows, shift the group and
>> other bits out to obtain the user bits, and then dispatch on the values
>> to get read and write access or read-only access.
>>
>> With these patches in place, the tests pass once again on mingw-msys.
>>
>> Why we never noticed before?  The POSIX tests were extended in ffe553,
>> and the read-lines-test was added in cfa1e7, both of which were added
>> somewhere between 5.2.0 and 5.3.0rc1.  And on *nix these tests work
>> fine, of course...
>
>Thanks.  I could not test your patches on Windows (because I don't have
>a Windows system), but the changes make sense to me and don't break
>things on Linux, where I tested them.  So I pushed them to both master
>and prerelease.
>
>All the best.
>Mario