Bug 238197
| Summary: | [FUSEFS] fusefs supports neither chflags(2) not stat.st_birthtim | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Alan Somers <asomers> | ||||
| Component: | kern | Assignee: | Alan Somers <asomers> | ||||
| Status: | New --- | ||||||
| Severity: | Affects Many People | CC: | cem, emaste, jSML4ThWwBID69YC, sean | ||||
| Priority: | --- | ||||||
| Version: | CURRENT | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| URL: | https://reviews.freebsd.org/D20453 | ||||||
| Attachments: |
|
||||||
Can you post the patch on phabricator? Review added. Thanks! Is this why the chflags command does not work? EX: chflags schg directory Expected behavior is the directory is immutable. Actual behavior is that nothing has changed, and the directory can be deleted as if the immutable flag is not set. Tested on FuseFS with MooseFS on FreeBSD 13.1-p2. (In reply to jSML4ThWwBID69YC from comment #4) Yes, exactly. (In reply to Alan Somers from comment #5) Thank you for confirming. Here's a vote to implement this feature, assuming it's possible. It's really quite useful. (In reply to jSML4ThWwBID69YC from comment #6) It's possible. In fact it isn't even difficult, technically. The hard part is that the protocol change needs to be coordinated with the Linux and libfuse communities. It's a people problem, not a coding problem. (In reply to Alan Somers from comment #7) Is this something that needs to be brought up at https://github.com/libfuse/libfuse A quick look and I don't see anything in relation to the chflags command. I'm not sure there is an equivalent in Linux. (In reply to jSML4ThWwBID69YC from comment #8) Actually, libfuse follows the Linux kernel. So this is something that needs to be brought up with Linux. Basically, we need to add an struct fuse_attr { .... #ifdef FreeBSD uint32_t file_flags uint64_t birthtime; uint32_t birthtimensec; #endif } along with the backwards-compatibility stuff. None of those fields will be used for Linux. Basically, we'll be asking Linux to be our documentation, so as to avoid the need to fork libfuse. Has this been brought up the Linux developers? Unfortunately, all I can do is provide testing, when and if this feature becomes available. (In reply to jSML4ThWwBID69YC from comment #10) Nope. Nobody has volunteered to do the required cat herding. |
Created attachment 204675 [details] Add st_birthtime support to FUSEFS backwards-incompatibly The FUSE protocol does not support chflags(2) at all, and the FUSE_GETATTR and FUSE_SETATTR messages have no fields for st_birthtime. This is a direct result of its Linux-only origins. OSXFuse extended the protocol to add those features (and others), but they had to fork libfuse to do it. FreeBSD has thus far had a policy of no changes to libfuse. Even if we were to abandon that policy, we can't add chflags and st_birthtime support without bumping the FUSE kernel API version past the most recently published version in libfuse. The reason is because libfuse includes its own copy of the kernel API header. Changing the FUSE protocol without reving the kernel API past what is already published by libfuse would thus break existing binaries. Attached is a patch that adds st_birthtime support to fusefs(5). However, it adds it at protocol version 7.9, so it breaks compatibility with existing binaries. The patch also includes some OSX definitions. I thought that including them would make it easier to update libfuse.