On Mon, Jan 18, 2021 at 6:45 PM Kevin Peng <kkpeng...@gmail.com> wrote:
>
> 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

Addendum: Similarly, if I add an $LXMOD to the block and char devices
by using the commands

setfattr -h -v 
0x1400000000060400244c584d4f4400a4610000001800000000060800244c5844455600340200006705000000
-n system.ntfs_ea block

and

setfattr -h -v 
0x1400000000060400244c584d4f4400a4210000001800000000060800244c5844455600230100005604000000
-n system.ntfs_ea char

then WSL correctly identifies them as block and char devices
respectively, with permissions 644.


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

Reply via email to