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