Hi Kevin,
Jean-Pierre André wrote on 1/9/21 9:29 PM:
Hi,
Kevin Peng wrote on 1/9/21 5:00 PM:
Hello Jean-Pierre,
I created the following symlinks in WSL in a test directory, along
with a file named "foo" and a directory named "bar":
relative-symlink-to-file -> foo
relative-symlink-to-dir -> bar
relative-symlink-to-nonexistent -> nonexistent
absolute-symlink-to-file -> /mnt/d/testsymlink/foo
absolute-symlink-to-dir -> /mnt/d/testsymlink/bar
absolute-symlink-to-nonexistent -> /nonexistent
(Note that WSL sometimes creates native Windows symlinks and sometimes
creates its own WSL symlinks; I took care to ensure that all of the
symlinks I created were of the latter type.)
Great !
getfattr simply fails with EIO when I try to issue the commands you
requested. I did run ntfsinfo on the symlinks though. I have included
That is strange. Maybe you did not use the -h option of fgetattr ?
Anyway, as you posted the full ntfsinfo, I now have the full
picture. I see that symlinks to directories are based on a
regular file pattern, which is a major difference from
Windows symlinks.
the full output at the bottom of this email. The principal finding is
that the reparse point data is the bytes 02000000 followed by the
This field must have some meaning...
contents of the symlink. Mirroring POSIX semantics, it appears that
the type or existence of the target has no effect on the format of the
reparse point data. I'll try this again with a non-ASCII symlink
target to verify which encoding it uses.
$ sudo ntfsinfo -F /testsymlink/relative-symlink-to-file /dev/nvme0n1p7
[...]
I tried such a relative symlink on Windows 10 and I was
disappointed to see it was not supported and it appeared
as a regular file. There is no improvement over the Interix
implementation.
I saw that reparse tags have been defined for all special
files, so better also implement them in the same step.
Can you also post the ntfsinfo output for a fifo, a char
device and a block device ? For sockets I will probably
have to make some guess work, but having the same layout
as WSL is probably not essential.
Jean-Pierre
I have uploaded to
https://jp-andre.pagesperso-orange.fr/ntfs-3g_ntfsprogs-2017.3.23AB.6-2.tgz
a test version of ntfs-3g with support for WSL-type symlinks.
This variant is enabled by using the mount option :
special_files=wsl
Both the Interix symlinks and the WSL ones are recognized
irrespective of the option being used. The option only acts
on new symlinks being created.
Please test it, and report.
The sockets, fifos, character and block devices are also
implemented the same way.... but I have no valid example
of how WSL implements them, so this is probably plain wrong.
Would you please use WSL to create some of them and post
their ntfsinfo description :
mknod path/fifo p
mknod path/chr c 0x123 0x456
mknod path/blk b 0x234 0x567
Thanks,
Jean-Pierre
_______________________________________________
ntfs-3g-devel mailing list
ntfs-3g-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
