On Fri, Jan 15, 2021 at 7:57 AM Jean-Pierre André
<jean-pierre.an...@wanadoo.fr> wrote:
> > So I've tried creating some links and special files with the
> > special_files=wsl mount option, and reading those in WSL. WSL was
> > successfully able to read links I created to "dir", "file", "文件", and
> > "\x17\x15\ufffe\uffff". The fifos, block and char special devices look
> > like empty regular files to WSL though (with no permissions, and owned
> > by whichever user and group was specified in the DrvFS mount options).
>
> Fine, so the symlink target is utf8 encoded.
>
> I have uploaded a new test version on
> https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-3.tgz
> with fifo and char and block device according to your example.
>
> However ownership and permissions are not inserted into the EA.
> This may be a problem as permissions are merged with the type
> to form the $LXMOD. WSL might require the $LXMOD to be present
> and match the type defined by the reparse tag.
>
> I hope ownership and permissions are not required, and this
> would be consistent with WSL being able to process Windows
> files without polluting them.
>
> If the fifo with no $LXMOD is not recognized by WSL, would you
> please add it to an existing fifo as shown below (long lines
> could be split by the mailer)
>
> (adding $LXMOD only)
> # mknod wsl/fifo-1 p
> # setfattr -h -v 0x1400000000060400244c584d4f4400a411000000 -n
> system.ntfs_ea wsl/fifo-1
>
> (adding $LXUID, $LXGID and $LXMOD)
> # mknod wsl/fifo-2 p
> # setfattr -h -v
> 0x1400000000060400244c5855494400e8030000001400000000060400244c5847494400e8030000001400000000060400244c584d4f4400a411000000
> -n system.ntfs_ea wsl/fifo-2

So your most recent version of ntfs-3g indeed interprets WSL-generated
block, char, fifos, and symlinks correctly.

The very interesting behavior is when WSL tries to interpret the
ntfs-3g generated block, char and fifos:
 - getdents64() correctly identifies those files as a block, char and
fifo respectively.
 - However, statx() thinks the block and char files are regular files,
and returns ENOENT when one tries to stat() the fifo.

Adding $LXMOD to the fifo, however, resulted in correct behavior: in
my case, the ls -l output for that fifo (in my case) is prw-r--r--.
Adding $LXUID and $LXGID was not required.

Best,
  Kevin


_______________________________________________
ntfs-3g-devel mailing list
ntfs-3g-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel

Reply via email to