Rclone mount and Posix Compliance/ Permission meta data for files

[Jue_Sch]

Hi,

upfront I want to mention what a great tool rclone mount is and how much it helps. Impressed by what it can do compared to other fuse plugins for object storage, I wondered how close it is to posix compliance.

I searched for test suites and found : Linux POSIX file system test suite [LWN.net]

I know it is rather old but I assumed that the standard also did not change recently and that it would be still valid.

A working link is this: http://download.tuxera.com/sw/qa/pjd-fstest-20090130-RC.tgz

A search in github also showed that it is used in another fuse project (unrelated to Object Storage) as part of the travis job to do a verification after each build.

So I thought I give it a try and ran the suite over an rclone mount.

The results were not great , but not due to a lot of missing functions but due to the fact that the suite does combine a lot of test cases with different permission right checks and as rclone (to my knowledge) does not use meta data to store permission infos for individual files/folders it cannot work.

That raised these questions

1.) Is Posix compliance something rclone mount tries to achieve? I mean things like hardlinks, softlinks most likely cannot work but leaving those out, is the intention to get close to it?

2.) Is the capability to store permission changes users perform on individual files something that is on the project roadmap or is something like this considered out of the goal of the project (I know that permissions can be set globally for files and folders but for script execution this would mean all is marked executable per default if one file needs to be executable)

[Animosity022]

@Jue_Sch

Is Posix compliance something rclone mount tries to achieve? I mean things like hardlinks, softlinks most likely cannot work but leaving those out, is the intention to get close to it?

Lots of POSIX stuff doesn't work on fuse because it's sitting on a Cloud storage system that has no concept of what they are. Majority of new things are tracked via issues:

Hard links: mount: symbolic and hard links needed · Issue #4980 · rclone/rclone · GitHub as an example

@Jue_Sch

Is the capability to store permission changes users perform on individual files something that is on the project roadmap or is something like this considered out of the goal of the project (I know that permissions can be set globally for files and folders but for script execution this would mean all is marked executable per default if one file needs to be executable)

This goes back to the cloud remotes as they have no concept of Linux permissions that you are asking about, much like mounting on Windows as that has no concept of Linux permissions. FUSE based file system are meant to be seen by the user. For other users to see them, you have to use --allow-other and you can set the UID/GID/file permissions on the mount via the command line since the remote doesn't know about this info.

[Jue_Sch]

Looking at S3 specifically, aren't meta data headers like this: x-amz-meta-file-permissions meant to be used to store such info? Or is this something different? Just curious

[Animosity022]

Rclone works on many, many remotes and not just S3.