Remove flag and padding in rename operation when using libfuse

[nicolaspapp]

No description provided.

[cberner]

This seems like the wrong fix to me. Linux is the only supported OS with not(libfuse), so this config can never be reached on MacOS. Should we just revert that flags field?

[FirelightFlagboy]

Maybe we just need to remove that line from build.rs:

fuser/build.rs

Line 23 in a760aae

println!("cargo:rustc-cfg=feature=\"macfuse-4-compat\"");

?

[nicolaspapp]

I see. I was assuming that at some point in the future, supporting Mac without libfuse could be an option.

Regarding @FirelightFlagboy proposal, I think removing the fields would be the simplest solution. If Mac without libfuse is not an option, those fields are never going to be used. We can probably just get read off the fields and the macfuse-4-compat flag altogether.

Another option, which seems a lot more complicated but could be useful if you expect, at some point in time, having a pure Rust implementation for Mac, could be the following:
#[cfg(target_os = "macos", not(feature = "libfuse"), feature = "macfuse-4-compat")]

Since:

• It disables when libfuse is enabled since it does not use this flags.
• It will automatically support start using those flags if Mac without libfuse is ever an option
• You can use the feature tag macfuse-4-compat for macfuse < 4

@cberner your call. They are all fine for me, my only objective here is just to get the rename operation working on Mac.

[FirelightFlagboy]

It still surprising, because macFuse still define those fields: https://github.com/osxfuse/fuse/blob/2f5d04ada43b42bde3c0ce49c5a5d977bce2b0f2/include/fuse_kernel.h#L446-L452

[nicolaspapp]

@FirelightFlagboy I think they are compensating for it here

[cberner]

@nicolaspapp what MacFuse version are you using? It looks like the current code was to fix an issue with MacFuse >=4.0 (#307). However, now that I'm looking at build.rs I think the problem might be this line:

fuser/build.rs

Line 17 in 9f6ced7

.atleast_version("2.6.0")

we're enabling the macfuse-4-compat feature for MacFuse >= 2.6, which seems like it will break for 2.6 <= x < 4.0

[nicolaspapp]

I am using the latest. Version 5.0.1.

I believe it might be related to to what happens on fuse_lowlevel.c:1304

FUSE_COMPAT_RENAME_IN_SIZE introduces an 8 bytes offset, which is the size of flags and padding variables

[cberner]

Oh interesting, do we just need to add that FUSE_CAP_RENAME_SWAP check then?

[nicolaspapp]

@cberner yes, apparently they are using that flag to determine wether flags and padding should be read.
Then they read flag to determine whether is a common rename or a swap rename.

[FirelightFlagboy]

I've tested a simple rename with your branch and it work in the shell, but I know it's simpler with the shell than in finder, did test renaming a file with finder.app?

Macfuse: 4.10.1
Macos: 15.5

[nicolaspapp]

@FirelightFlagboy under what situations was this initially breaking? Because what I have so far in the branch is basically reverting #307.

Based on what I see on the actual code fuse_rename_in should account for flags and padding only if FUSE_CAP_RENAME_SWAP is enabled. Now, it is not clear to me yet where that could be being set.

[FirelightFlagboy]

@FirelightFlagboy under what situations was this initially breaking? Because what I have so far in the branch is basically reverting #307.

The problem + investigation is detailed in the first comment: #307 (comment)

Based on what I see on the actual code fuse_rename_in should account for flags and padding only if FUSE_CAP_RENAME_SWAP is enabled. Now, it is not clear to me yet where that could be being set.

Maybe FUSE_CAP_RENAME_SWAP was enabled by default before, and now it's not 🤔

[nicolaspapp]

@FirelightFlagboy I found something...

This is what I got so far:

1. Looks they first added experimental renamex support, and this is when they added the fields: macfuse/library@f95e939

2. Then, later added the official support, adding that flag: macfuse/library@3ec24b8

I believe the first one was introduced at macFUSE 4.0.0. The second one seems to match 4.0.3 release description:

I think it might have been the default at some point, but ultimately what defines the FUSE_CAP_RENAME_SWAP is whether the renamex operation is defined in the FileSystem as shown here

I'm not sure why you were still seeing this issue in 4.8

[fix]

i confirm i need this PR to fix an issue i get with rename implementation in fuser : the file name being passed is corrupted (first characters being dropped)