Kevin Peng wrote on 1/19/21 8:57 AM:
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.
Fine and thanks for testing.
So I have added a $LXMOD for special files except symlinks.
It contains a redundant mode, with the permissions hard coded
as 0644.
After cleaning the code and inserting the $LXMOD, I have uploaded
the updated tarball to :
https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-4.tgz
Unless something undesirable is found, this could be the next
version ntfs-3g_ntfsprogs-2017.3.23AR.6.
Jean-Pierre
_______________________________________________
ntfs-3g-devel mailing list
ntfs-3g-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
