Re: [PATCH 0/3] fix unlink/rename failure in hyper-v container

[Yoshinao Muramatsu <ysno@ac.auone-net.jp>]

On 2023/03/18 19:01, Corinna Vinschen wrote:
>> In the logs, here we can find some differences.
>> But I believe it is unclear if it will always be so.
>> If additional inspections are done, they will be costly.
> 
> Assuming we can pull some information from the filesystem flags, the
> cost is negligible.  We just check bits in a filesystem bitmask.

I was expecting something like checking the file system driver
configuration as an additional test.
It would be ideal if the checks could be done at no additional cost.

> Assuming we can fetch useful info from the filesystem flags, we could
> basically do both, add your patch to have a workaround in case the
> Windows call returns INVALID_PARAMETER, and an early test for a FS
> flag which can be used down the road to avoid the workaround.

Adding workarounds can be done now and adding early testing
can be done once the judgment conditions are known. Great.

> This is disappointing.  One of the newer filesystem flags is
> 0x400, FILE_SUPPORTS_POSIX_UNLINK_RENAME.  As you can see,
> the flag is set.  But the POSIX functionality doesn't work
> here, right?

I was not aware that there was a FILE_SUPPORTS_POSIX_UNLINK_RENAME there.
I was only looking at the part where there was a difference.
Right, FILE_SUPPORTS_POSIX_UNLINK_RENAME doesn't work
on mounted volume with hyper-v isolation.

I additionally checked with the ltsc2016 version of the hyper-v container.
POSIX_UNLINK_RENAME should not be supported from the windows version,
but interesting results were obtained.
FILE_SUPPORTS_POSIX_UNLINK_RENAME is not considered to work,
but has not been tested.

> However, what's really curious here is the fact that the
> FILE_SUPPORTS_OPEN_BY_FILE_ID flag is missing.
> 
> NTFS always supports this since Windows 2003!  So we could
> use this flag as indicator that, probably, POSIX rename/unlink
> won't work.

I thought that if there was no FILE_SUPPORTS_OPEN_BY_FILE_ID
and OpenByFileId() worked, it would be a Signature,
but the result was different.

I tested OpenByFileID() on a bind-mounted directory, it was failed.
Maybe it's because of the path isolation.
ltsc2022 process isolation says "I support it" but it not works.
Okay, it's not a security issue. So now I'm writing this here.

Unfortunately, the state of the FILE_SUPPORTS_OPEN_BY_FILE_ID flag
does not match the actual behavior, so I fear it may be corrected.

FileSystemAttributes on containers
image   isolation mounted? FileSystemAttributes
ltsc2016 hyper-v  normal  0x1c700df        +OPEN_BYID
ltsc2022 hyper-v  normal  0x1c706df        +OPEN_BYID +POSIX +CLEANUP
ltsc2022 process  normal  0x1c706df        +OPEN_BYID +POSIX +CLEANUP
ltsc2016 hyper-v  binded  0x2c706ff +USN_J            +POSIX +CLEANUP +QUOTA
ltsc2022 hyper-v  binded  0x2c706ff +USN_J            +POSIX +CLEANUP +QUOTA
ltsc2022 process  binded  0x3e706ff +USN_J +OPEN_BYID +POSIX +CLEANUP +QUOTA

OpenByFileId and POSIX_UNLINK_RENAME test result
image    isolation mounted? OpenByFileId POSIX_UNLINK_RENAME
ltsc2016 hyper-v   normal   success      fail?(windows version)
ltsc2022 hyper-v   normal   success      success
ltsc2022 process   normal   success      success
ltsc2016 hyper-v   binded   fail         not tested
ltsc2022 hyper-v   binded   fail         fail
ltsc2022 process   binded   fail         success

ps
Corinna, I read the new email about fs_info::update patch
you posted while I was writing this.
I will report back when I test it, but it may take some time
as I usually use msys2 and don't have a cygwin development environment.

-- 
Yoshinao Muramatsu <ysno@ac.auone-net.jp>