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

[Corinna Vinschen]

On Mar 22 00:32, Yoshinao Muramatsu wrote:
> > Wait.  I might have misunderstood something.  This is about accessing a
> > host NTFS from inside a Hyper-V isolated process, right?  So from the
> > point of view of the Hyper-V isolated Cygwin process, the NTFS
> > filesystem is a *local* filesystem?  Or is it mapped as a remote
> > filesystem?
> > 
> > The difference is important, because my patch would only change the
> > outcome if the Cygwin process in the Hyper-V container gets the
> > NTFS filesystem presented as a remote filesystem.
> > 
> > I noticed this problem when I was looking into implementing the
> > FILE_SUPPORTS_OPEN_BY_FILE_ID flag checking.  I have a different
> > solution from the one I pushed today in the loop which probably
> > makesmuch more sense and is independent of the subtil difference
> > between loca and remote FS.
> 
> I don't understand the whole picture, so I may be missing the point.
> So I will report only the points I am sure of.
> 
> The file system on the host side is the local disk.
> In the container, it appears to be exposed as a ntfs local
> file system because unlink_nt() tries to use posix unlink semantics.

Right.  That and the fact that the filesystem characteristic don't have
the FILE_REMOTE_DEVICE flag set, as your getVolInfo output already
shows.  I could just have re-read your mail instead of asking redundant
questions, sorry!

I pushed a new Cygwin DLL, test release 3.5.0-0.251.gfe2545e9faaf.
This should do what we want, now.  If you can confirm, I'll push
your workaround afterwards.


Thanks,
Corinna