Date: Thu, 25 Jan 2024 01:06:26 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 276602] [fusefs]: invalid value for st_birthtime.tv_nsec Message-ID: <bug-276602-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276602 Bug ID: 276602 Summary: [fusefs]: invalid value for st_birthtime.tv_nsec Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: asomers@FreeBSD.org If a file system's on-disk format does not support st_birthtime, it isn't c= lear what value it should return in stat(2). Neither our man page nor the OpenG= roup specifies. But our convention is to return { .tv_sec =3D -1, .tv_nsec =3D = 0 }.=20 fusefs is different. It returns { .tv_sec =3D -1, .tv_nsec =3D -1 }. It's= done that ever since the initial import in SVN r241519. Most software apparently handles this just fine. It must, because we've ha= d no complaints. But the Rust standard library will panic when reading such a timestamp during std::fs::metadata, even if the caller doesn't care about t= hat particular value. That's a bug, and should be fixed. But we can help out = by never returning such values. https://github.com/rust-lang/rust/issues/108277 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-276602-227>