If a file system's on-disk format does not support st_birthtime, it isn't clear what value it should return in stat(2). Neither our man page nor the OpenGroup specifies. But our convention is to return { .tv_sec = -1, .tv_nsec = 0 }. fusefs is different. It returns { .tv_sec = -1, .tv_nsec = -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 had 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 that 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
Out of curiosity does FUSE on Linux do the same thing?
On Linux birthtime is reported via statx(2), not stat(2). And statx has a stx_mask field to tell the caller which fields are valid. Calling statx on a file on a fuse mountpoint, the valid bit is not set for btime.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=55b80e2ca52c4b27c4920d372a6e71ac9ab7da9e commit 55b80e2ca52c4b27c4920d372a6e71ac9ab7da9e Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2024-01-25 15:19:37 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2024-02-04 21:01:06 +0000 fusefs: fix invalid value for st_birthtime.tv_nsec If a file system's on-disk format does not support st_birthtime, it isn't clear what value it should return in stat(2). Neither our man page nor the OpenGroup specifies. But our convention for UFS and msdosfs is to return { .tv_sec = -1, .tv_nsec = 0 }. fusefs is different. It returns { .tv_sec = -1, .tv_nsec = -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 had 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 that particular value. That's a separate bug, and should be fixed. Change our invalid value to match msdosfs and ufs, pacifying the Rust standard library. PR: 276602 MFC after: 1 week Sponsored by: Axcient Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D43590 sys/fs/fuse/fuse_internal.c | 1 - sys/fs/fuse/fuse_node.c | 7 +++++++ tests/sys/fs/fusefs/getattr.cc | 15 +++++++++------ tests/sys/fs/fusefs/lookup.cc | 15 +++++++++------ 4 files changed, 25 insertions(+), 13 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=739488cc21b1ad08994aa5c36d85b9c11866b29d commit 739488cc21b1ad08994aa5c36d85b9c11866b29d Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2024-01-25 15:19:37 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2024-02-12 17:43:11 +0000 fusefs: fix invalid value for st_birthtime.tv_nsec If a file system's on-disk format does not support st_birthtime, it isn't clear what value it should return in stat(2). Neither our man page nor the OpenGroup specifies. But our convention for UFS and msdosfs is to return { .tv_sec = -1, .tv_nsec = 0 }. fusefs is different. It returns { .tv_sec = -1, .tv_nsec = -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 had 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 that particular value. That's a separate bug, and should be fixed. Change our invalid value to match msdosfs and ufs, pacifying the Rust standard library. PR: 276602 Sponsored by: Axcient Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D43590 (cherry picked from commit 55b80e2ca52c4b27c4920d372a6e71ac9ab7da9e) sys/fs/fuse/fuse_internal.c | 1 - sys/fs/fuse/fuse_node.c | 7 +++++++ tests/sys/fs/fusefs/getattr.cc | 15 +++++++++------ tests/sys/fs/fusefs/lookup.cc | 15 +++++++++------ 4 files changed, 25 insertions(+), 13 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=65e25e4a614a99243e7419279b294e399991dfff commit 65e25e4a614a99243e7419279b294e399991dfff Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2024-01-25 15:19:37 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2024-02-12 18:02:50 +0000 fusefs: fix invalid value for st_birthtime.tv_nsec If a file system's on-disk format does not support st_birthtime, it isn't clear what value it should return in stat(2). Neither our man page nor the OpenGroup specifies. But our convention for UFS and msdosfs is to return { .tv_sec = -1, .tv_nsec = 0 }. fusefs is different. It returns { .tv_sec = -1, .tv_nsec = -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 had 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 that particular value. That's a separate bug, and should be fixed. Change our invalid value to match msdosfs and ufs, pacifying the Rust standard library. PR: 276602 Sponsored by: Axcient Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D43590 sys/fs/fuse/fuse_internal.c | 1 - sys/fs/fuse/fuse_node.c | 7 +++++++ tests/sys/fs/fusefs/getattr.cc | 15 +++++++++------ tests/sys/fs/fusefs/lookup.cc | 15 +++++++++------ 4 files changed, 25 insertions(+), 13 deletions(-)
A commit in branch releng/13.3 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f2c72486da30eda54f0db1a9b7ca822afc835ecf commit f2c72486da30eda54f0db1a9b7ca822afc835ecf Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2024-01-25 15:19:37 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2024-02-12 20:17:13 +0000 fusefs: fix invalid value for st_birthtime.tv_nsec If a file system's on-disk format does not support st_birthtime, it isn't clear what value it should return in stat(2). Neither our man page nor the OpenGroup specifies. But our convention for UFS and msdosfs is to return { .tv_sec = -1, .tv_nsec = 0 }. fusefs is different. It returns { .tv_sec = -1, .tv_nsec = -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 had 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 that particular value. That's a separate bug, and should be fixed. Change our invalid value to match msdosfs and ufs, pacifying the Rust standard library. PR: 276602 Sponsored by: Axcient Reviewed by: emaste Approved by: re (cperciva) Differential Revision: https://reviews.freebsd.org/D43590 (cherry picked from commit 65e25e4a614a99243e7419279b294e399991dfff) sys/fs/fuse/fuse_internal.c | 1 - sys/fs/fuse/fuse_node.c | 7 +++++++ tests/sys/fs/fusefs/getattr.cc | 15 +++++++++------ tests/sys/fs/fusefs/lookup.cc | 15 +++++++++------ 4 files changed, 25 insertions(+), 13 deletions(-)