fs: track all files as potential hardlinks

While pairing with Timothée we discovered that the examples don't work
on his system because the `cfsctl create-image` on the inside of the
container build fails to detect all hardlinks.  The difference is that
his podman storage driver is using fuse-overlayfs, which doesn't always
accurately report `st_nlink`.  The behaviour is odd: when observing the
hardlink via the first filename it will report a given `(st_dev,
st_ino)` with `st_nlink` of 1 but when inspecting it via the second
filename it will report the same `(st_dev, st_ino)` but with `st_nlink`
of 2 this time.

Let's just be "less clever" and store all non-directory inodes in our
hashtable as potential hardlinks.

See containers/fuse-overlayfs#435

Signed-off-by: Allison Karlitskaya <[email protected]>
Co-Authored-By: Timothée Ravier <[email protected]>

Author: allisonkarlitskaya

src/fs.rs

@@ -237,15 +237,16 @@ impl FilesystemReader<'_> {
 
         let (buf, stat) = FilesystemReader::stat(&fd, ifmt)?;
 
-        if let Some(leafref) = self.inodes.get(&(buf.st_dev, buf.st_ino)) {
+        // NB: We could check `st_nlink > 1` to find out if we should track a file as a potential
+        // hardlink or not, but some filesystems (like fuse-overlayfs) can report this incorrectly.
+        // Track all files.  https://github.com/containers/fuse-overlayfs/issues/435
+        let key = (buf.st_dev, buf.st_ino);
+        if let Some(leafref) = self.inodes.get(&key) {
             Ok(Rc::clone(leafref))
         } else {
             let content = self.read_leaf_content(fd, buf)?;
             let leaf = Rc::new(Leaf { stat, content });
-            if buf.st_nlink > 1 {
-                self.inodes
-                    .insert((buf.st_dev, buf.st_ino), Rc::clone(&leaf));
-            }
+            self.inodes.insert(key, Rc::clone(&leaf));
             Ok(leaf)
         }
     }