XAttr backend for VFS #2793
XAttr backend for VFS #2793
Conversation
er-vin
requested review from
sbeyer,
camilasan,
allexzander,
DominiqueFuchs and
FlexW
|
/rebase |
github-actions
bot
force-pushed
the
xattr_backend_for_vfs
branch
from
c731959 to
9656d6f
Compare
er-vin
force-pushed
the
xattr_backend_for_vfs
branch
from
9656d6f to
0b4bddc
Compare
Ideally this will end up being the backend we use for both Linux and macOS but that will require work with desktop environments on the Linux side and to reverse engineering at least on xattr value on macOS. Signed-off-by: Kevin Ottens <[email protected]>
Otherwise backends can't get to the actual file which will be needed for the XAttr backend. Signed-off-by: Kevin Ottens <[email protected]>
Indeed, that file size will almost always change between the 1 byte placeholder and the hydrated file. Only when using the CfAPI on Windows this won't be the case since because it will expose the original size even for placeholders. Also worth noting: the suffix backend didn't hit that case since the filename changes (with suffix for placeholders, without for hydrated files). Signed-off-by: Kevin Ottens <[email protected]>
Signed-off-by: Kevin Ottens <[email protected]>
er-vin
force-pushed
the
xattr_backend_for_vfs
branch
from
0b4bddc to
1aeb77c
Compare
|
@er-vin I'd say - squash 'em all, but I've approved already. Feel free to re-request if you squash them eventually. |
Well, I'd rather keep them like this. Each commit has a purpose on the steps to create the backend. It's generally the "fix this, fix that, adjust commit style, oh damn I stumbled there" commits which I try to purge from the history. But as long as they are showing a clear reasoning path there's more value in keeping them IMHO. |
|
Alright, let's wait for the CI now... |
|
AppImage file: Nextcloud-PR-2793-1aeb77c967db8b54d58d5009df432ca24b869654-x86_64.AppImage |
Plan is to use it on macOS and Linux but some extra work is required before making it the default choice. Indeed apart from the obvious "this needs more testing" there is also the need for growing Linux support for our attribute first and to implement the macOS support for the com.apple.LaunchServices.OpenWith attribute.
Obviously earmarked for use on macOS (even though "not only macOS"), different approach to what is hinted at in #1337 which I argue is not the best way to go about it for this project.