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

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

Hi Yoshinao,

On Mar 18 14:29, Yoshinao Muramatsu wrote:
> Hi Corinna.
> I'm Yoshinao Muramatsu. Thank you for your thoughtful guidance.
> I have not modified the patch yet,
> but I have made some observations and post the results.
> 
> I forgot to mention in my first post that there is a workaround
> for this issue, which is to use process isolation unless
> hyper-v isolation is absolutely necessary
> (mainly caused by build number difference between host and container).

Ok, but that's a propoerty we'll never be able to test.

> 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 would also like to see better support for POSIX unlink/rename
> semantics in the container mechanism.

Yeah, but... do you have high hopes?

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.

> Therefore, I think it is not a bad idea to simply retry rather than spending
> time every time to check the conditions to deal with rare situations.
> However, in certain situations it happens all the time.
> (So if we can cache it that would be great.)
> But performance in the vast majority of other situations is more important.

The filesystem info is cached, so the filesystem flags are only checked
the first time we open a file on the filesystem.

> In the following logs, c:\ is the normal ntfs volume in the container,
> andc:\opt is the volume of the bind mounted host.
> Where the differences are
> - 0x00000020 Supports Disk Quotas
> - 0x01000000 Supports Open By FileID
> - 0x02000000 Supports USN Journal

I just updated the csih package to 0.9.13.  The getVolInfo tool
now prints *all* known filesystem flags.

> == hyper-v container (has issue)
> $ mount
> C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin64 on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> 
> $ /usr/lib/csih/getVolInfo.exe /cygdrive/c/
> Device Type        : 7
> Characteristics    : 20020
> Volume Name        : <>
> Serial Number      : 3456656850
> Max Filenamelength : 255
> Filesystemname     : <NTFS>
> Flags              : 1c706df
> ...snip...
> 
> $ /usr/lib/csih/getVolInfo.exe /cygdrive/c/opt/
> Device Type        : 7
> Characteristics    : 20020
> Volume Name        : <>
> Serial Number      : 955187689
> Max Filenamelength : 255
> Filesystemname     : <NTFS>
> Flags              : 2c706ff
> ...snip...

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?

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.


Corinna