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