kern/60676: mount_exfat reports duplicate inode 0 for all files and directories, causing false filesystem cycles

["alvaradorad%disroot.org@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60676
>Category:       kern
>Synopsis:       mount_exfat reports duplicate inode 0 for all files and directories, causing false filesystem cycles
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 01 15:00:00 +0000 2026
>Originator:     Alfredo Alvarado
>Release:        NetBSD 11.0
>Organization:
None - Freelance worker
>Environment:
NetBSD leap 11.0_STABLE NetBSD 11.0_STABLE (GENERIC) #0: Wed Aug 19 11:51:58 UTC 2026  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64

>Description:
On NetBSD 11.0, the exFAT implementation (whether invoked via mount.exfat, mount.exfat-fuse, or mount_puffs) fails to populate unique or valid inode numbers (st_ino) for any object in the filesystem. 

Running 'ls -id' on any file or directory inside the mounted exFAT partition returns an inode value of exactly 0, indicating a null or missing inode.

Because of this, or so I strongly suspect, 'cp -r', 'ls -R', or 'pax' enter a panic state. When they encounter sequential duplicate inode 0 values across the hierarchy, they erroneously detect a loop and abort with the message: "directory causes a cycle" or "File system cycle found at...".

Interestingly, 'tar' works perfectly fine.


mkdir -p ~/FAc2
tar cf - -C FAc . | tar xf - -C ~/FAc2


>How-To-Repeat:
1. Mount any exFAT partition using any of the available system commands:
   $ sudo mount_puffs mount.exfat#/dev/dk0 /mnt/
   FUSE exfat 1.4.0 (libfuse3)
   $ sudo mount.exfat-fuse /dev/dk0 /mnt/
   FUSE exfat 1.4.0 (libfuse3)
   $ sudo mount.exfat -o rw /dev/dk0 /mnt 
   FUSE exfat 1.4.0 (libfuse3)
  
2. Attempt to copy or list subdirectories recursively:
   $ cp -r /mnt/RESPALDO2/FAc ~/
   cp: /mnt/RESPALDO2/FAc/Glosarios: directory causes a cycle
   cp: /mnt/RESPALDO2/FAc/Cursos: directory causes a cycle

   $ pax -rw -pp /mnt/RESPALDO2/FAc ~/
   pax: File system cycle found at /mnt/RESPALDO2/FAc/Glosarios
   pax: File system cycle found at /mnt/RESPALDO2/FAc/Cursos

   (All commands fail with directory cycle errors).

3. Check individual inodes using 'ls -id' inside the mount point:
   
   $ ls -id /mnt/RESPALDO2/FAc/Cursos/
   0 /mnt/RESPALDO2/FAc/Cursos/
   $ ls -id /mnt/RESPALDO2/FAc/Cursos/Amarillo.jpg 
   0 /mnt/RESPALDO2/FAc/Cursos/Amarillo.jpg
   $ ls -id /mnt/RESPALDO2/FAc/Glosarios/
   0 /mnt/RESPALDO2/FAc/Glosarios/
   $ ls -id /mnt/RESPALDO2/FAc/Glosarios/diccionario.pdf 
   0 /mnt/RESPALDO2/FAc/Glosarios/diccionario.pdf

4. Checking ls -R too:

   $ ls -R /mnt/RESPALDO2/FAc | grep ":"
   ls: Cursos: directory causes a cycle
   ls: Glosarios: directory causes a cycle

   
>Fix:
I am a desktop user, not a developer, but, according to my basic analysis, the exFAT driver or the PUFFS emulation layer is defaulting or initializing the 'st_ino' variable to 0 for all files and directories. The fix should involve ensuring that the system populates this field with a valid, non-zero virtual inode number so that standard system commands stop hitting false cycles.