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 <y...@ac.auone-net.jp>
