I mapped an entire host. It appears that some of those directory structures are self-referential. See below.
The problem now is that this is not reflected in any way on the mapped drive letter. Those inodes are entirely unique and there is no other indication that these directories are symbolic links or other links. See below.
This causes some third party tool to endlessly descend into this recursive structure. It could ordinarily detect the situation, if given data that actually represents the situation.
I believe if the inode numbers weren't seemingly randomly generated, but actually corresponded (in some way) to the host's actual inode numbers, then the same directory would have the same inode number, and such tools could abort their descent.
user@host /usr/bin/X11 % stat .
File: .
Size: 36864 Blocks: 80 IO Block: 4096 directory
Device: fd01h/64769d Inode: 1048862 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2026-01-02 12:19:09.281501542 +0100
Modify: 2025-11-13 17:53:47.311366097 +0100
Change: 2025-11-13 17:53:47.311366097 +0100
Birth: 2019-01-22 20:46:57.913220000 +0100
user@host /usr/bin/X11 % stat ./X11
File: ./X11 -> .
Size: 1 Blocks: 0 IO Block: 4096 symbolic link
Device: fd01h/64769d Inode: 1061910 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2026-01-02 18:49:20.635875970 +0100
Modify: 2017-05-03 11:38:16.000000000 +0200
Change: 2019-01-22 22:45:08.267473162 +0100
Birth: 2019-01-22 22:45:08.259473162 +0100
user@host /usr/bin/X11 % stat ./X11/X11
File: ./X11/X11 -> .
Size: 1 Blocks: 0 IO Block: 4096 symbolic link
Device: fd01h/64769d Inode: 1061910 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2026-01-02 18:49:20.635875970 +0100
Modify: 2017-05-03 11:38:16.000000000 +0200
Change: 2019-01-22 22:45:08.267473162 +0100
Birth: 2019-01-22 22:45:08.259473162 +0100
user@host /usr/bin/X11 %
Z:\usr\bin\X11>stat .
File: .
Size: 0 Blocks: 36 IO Block: 65536 directory
Device: 14f0583eh/351295550d Inode: 11286489447583759167 Links: 1
Access: (0755/drwxr-xr-x) Uid: (197610/ Chris) Gid: (197121/ Kein)
Access: 2026-01-02 12:19:09.000000000 +0100
Modify: 2025-11-13 17:53:47.000000000 +0100
Change: 2025-11-13 17:53:47.000000000 +0100
Birth: -
Z:\usr\bin\X11>stat .\X11
File: .\X11
Size: 0 Blocks: 36 IO Block: 65536 directory
Device: 14f0583eh/351295550d Inode: 6404748780561138043 Links: 1
Access: (0755/drwxr-xr-x) Uid: (197610/ Chris) Gid: (197121/ Kein)
Access: 2026-01-02 12:19:09.000000000 +0100
Modify: 2025-11-13 17:53:47.000000000 +0100
Change: 2025-11-13 17:53:47.000000000 +0100
Birth: -
Z:\usr\bin\X11>stat .\X11\X11
File: .\X11\X11
Size: 0 Blocks: 36 IO Block: 65536 directory
Device: 14f0583eh/351295550d Inode: 9794400630241004471 Links: 1
Access: (0755/drwxr-xr-x) Uid: (197610/ Chris) Gid: (197121/ Kein)
Access: 2026-01-02 12:19:09.000000000 +0100
Modify: 2025-11-13 17:53:47.000000000 +0100
Change: 2025-11-13 17:53:47.000000000 +0100
Birth: -
Z:\usr\bin\X11>
I mapped an entire host. It appears that some of those directory structures are self-referential. See below.
The problem now is that this is not reflected in any way on the mapped drive letter. Those inodes are entirely unique and there is no other indication that these directories are symbolic links or other links. See below.
This causes some third party tool to endlessly descend into this recursive structure. It could ordinarily detect the situation, if given data that actually represents the situation.
I believe if the inode numbers weren't seemingly randomly generated, but actually corresponded (in some way) to the host's actual inode numbers, then the same directory would have the same inode number, and such tools could abort their descent.