In Facter 3, if statvfs failed, then it excluded the size and available fields of the mountpoint: https://github.com/puppetlabs/facter/blob/6d7ffc6efdfbc3b1fc79311cdeb4581ac2098d9c/lib/src/facts/solaris/filesystem_resolver.cc#L49-L52 And all of the derived fields were set to 0: https://github.com/puppetlabs/facter/blob/6d7ffc6efdfbc3b1fc79311cdeb4581ac2098d9c/lib/src/facts/resolvers/filesystem_resolver.cc#L38-L39 And capacity was reported as 100%:
/dev/fd => { |
available => "0 bytes", |
available_bytes => 0, |
capacity => "100%", |
device => "fd", |
filesystem => "fd", |
options => [ |
"rw", |
"dev=xxx" |
], |
size => "0 bytes", |
size_bytes => 0, |
used => "0 bytes", |
used_bytes => 0 |
},
|
Facter 4 uses the statvfs gem, which raises if statvfs returns < 0 https://github.com/djberg96/sys-filesystem/blob/c00f568f3386329e21617174e2d1cd49a6a70fa8/lib/sys/unix/sys/filesystem.rb#L225 The Solaris mountpoint resolver needs to guard against Sys::Filesystem.stat raising and treat the mount has having available & total size 0 like we do in mac resolver: https://github.com/puppetlabs/facter/blob/d9d8324b02c26be2eb17a1d8ff26306a331431e2/lib/facter/resolvers/macosx/mountpoints.rb#L36-L44 Rather than requiring every caller to handle the exception, the FilesystemHelper should rescue the exception, log it at debug, and return a stat(like) object with the fields initialized to 0. |