To reproduce: `hexdump -s1 /compat/linux/proc/mounts` Fix: https://github.com/freebsd/freebsd-src/pull/989
It would seem better for pseudofs-based filesystems to correctly report file sizes instead. In particular, pfs_getattr() needs to set vap->va_size, possibly by calling the fill function with a dummy UIO_NOCOPY uio.
(In reply to Mark Johnston from comment #1) > It would seem better for pseudofs-based filesystems to correctly report file sizes I think this would require a pn_fill() (when !NULL) for every pfs_getattr() and defeat the purpose of stat() being faster than actually reading the file? Also it would diverge from what Linux does (their /proc would have 0-sized files and the behavior is documented, although I don't have an example of applications expecting this behavior..)
(In reply to Xin LI from comment #2) Does the performance consideration really matter in practice given that these files are typically quite small. I didn't know that /proc files in Linux have size 0 though, so perhaps my suggestion is a bad idea indeed.
(In reply to Xin LI from comment #2) The GNU tools expect this behaviour and adapt accordingly.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e23954bd42fe4331b67ba8f6446bcccf751096f1 commit e23954bd42fe4331b67ba8f6446bcccf751096f1 Author: Ricardo Branco <rbranco@suse.de> AuthorDate: 2024-01-03 20:17:58 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2024-01-04 08:16:50 +0000 hexdump: Do not trust st_size if it equals zero. Fix for hexdump -s not being able to skip files residing in pseudo-filesystems that advertise a zero size value. Historically, many pseudofs-based filesystems (e.g., procfs) report a va_size of 0 for numerous files classified as regular files. Typically, the contents of these files are generated on demand from kernel data as sbuf(9) strings at the time they are read. Accurately reporting the size of these files is challenging, as it often involves generating their contents. These pseudofs implementations frequently report the size as 0. This is a historical behavior and also aligns with Linux behavior. To maintain compatibility, we have chosen to preserve the existing behavior and address it in the userland application, rather than modifying it in the kernel (by updating the correct value for va_size). PR: bin/276106 MFC after: 1 week usr.bin/hexdump/display.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=538bf98c7c3ad65b6fa70cadd86635139c689097 commit 538bf98c7c3ad65b6fa70cadd86635139c689097 Author: Ricardo Branco <rbranco@suse.de> AuthorDate: 2024-01-03 20:17:58 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2024-12-22 07:49:29 +0000 MFC: hexdump: Do not trust st_size if it equals zero. PR: bin/276106 (cherry picked from commit e23954bd42fe4331b67ba8f6446bcccf751096f1) usr.bin/hexdump/display.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ff99541a14d7b8cf85e93774e939efde38a469b9 commit ff99541a14d7b8cf85e93774e939efde38a469b9 Author: Ricardo Branco <rbranco@suse.de> AuthorDate: 2024-01-03 20:17:58 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2024-12-22 07:49:50 +0000 MFC: hexdump: Do not trust st_size if it equals zero. PR: bin/276106 (cherry picked from commit e23954bd42fe4331b67ba8f6446bcccf751096f1) usr.bin/hexdump/display.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)