[BUG] spfs' fuse doesn't count hardlinks/nlink correctly

[dcookspi]

I think there's a bug in the spfs fuse implementation. I think it's in the nlink values it returns to other programs when they make stat calls to parts of a /spfs filesystem when the OverlayFsWithFuse backend (and probably FuseOnly) is being used.

We have a package where files go missing in the build stage. The package uses git submodules, one of them is a third-party tool that uses a Makefile to call a perl Makefile.PL script as part of the build. That script uses perl's File::Find module (version 1.20) to walk a directory to find things to copy around. But, this doesn't return all the files and dirs that it should from a directory under /spfs when OverlayFsWithFuse is enabled. Everything shows up when listing (ls) the directory, or using other programs to list the contents in the same environment, e.g. tree or find. But only one level is found by the File::Find call.

The File::Find implementation makes use of nlink (from stat-ing) to determine how many other subdirectories it has left to process when walking the filesystem. The fuse wrapper/implementation in spfs looks like it returns ok things for stat results (I don't know much about stat), but it has a TODO comment about the nlink values it gives back. I think that's the problem:

 ...
 // TODO: possibly return directory link count
 //       for all dirs below it (because of .. entries)
 nlink: if entry.is_dir() { 2 } else { 1 },
 ...

Expected behavior

spfs' fuse should return the correct value for the nlink field so things can reliably use that field.

The subdirectory where the files go missing in this build contains 2 sudirectories, 19 files, and no symlinks. So it's nlink value should be 4?

[dcookspi]

I have a fix for this that seems to work for the missing entries in the package build.