[BUG] spfs' fuse doesn't count hardlinks/nlink correctly #1020
Labels
agenda item
Items to be brought up at the next dev meeting
bug
Something isn't working
SPI AOI
Area of interest for SPI
SPI-0.41
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 theOverlayFsWithFuse
backend (and probablyFuseOnly
) 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'sFile::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
whenOverlayFsWithFuse
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
orfind
. But only one level is found by theFile::Find
call.The
File::Find
implementation makes use ofnlink
(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 aTODO
comment about thenlink
values it gives back. I think that's the problem: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?The text was updated successfully, but these errors were encountered: