abraunegg/onedrive

Feature Request: Unix permissions

Closed this issue · 6 comments

leonbottou commented

Is your feature request related to a problem? Please describe.

I have troubles using a git working directory inside OneDrive because Git and OneDrive conflict about the unix file permission bits. This leads to meaningless merge conflicts and messed up metadata in the git repository. The lack of predictable execute permission bits is very annoying. To work smoothly with git and github (a Microsoft property), OneDrive needs to pay more respect for Unix metadata...

Describe the solution you'd like

I believe this can be fixed by defining a custom facet named FileSystemInfoPosix containing Posix file modes. When uploading or updating a file on a Posix compatible system, the client should populate this facet. When downloading a file on a Posix compatible system, the client should request this facet, and, if found, set the file permissions accordingly.__

Describe alternatives you've considered

The FileSystemInfoPosix facet could contain other things, such as, for instance, the original Posix filename when the file was renamed because the original filename contains forbidden characters or conflicts with a similar finename with a different case. A source of inspiration might be the old Rock Ridge extension to iso9660. However I do not see much use in reconstructing device nodes or stuff like that.

Additional context

Maybe this could be prototyped in OneDrive4Unix and eventually coordinated with Microsoft?
That might work much better than the converse. Not clear to me.
Anyway, I am still very annoyed with my git directories inside onedrive.
They used to work nicely with dropbox...

abraunegg commented

When downloading a file on a Posix compatible system, the client should request this facet, and, if found, set the file permissions accordingly.

The issue(s) here are:

  • Detecting the POSIX file system .. what if you are using SMBv3 as a mounted directory to a Windows server .. that is not POSIX compliant, but you are running on a POSIX compatible platform (Linux / Unix)
  • Any SUID, SGID and sticky bit that might be set by the user (or git) - this is not supported by the D Programming Language - only standard permissions: https://dlang.org/library/std/file/set_attributes.html | https://dlang.org/library/std/file/get_attributes.html - thus cannot be read to create the facet , cannot write the facet permissions for that file | directory
  • What happens when the file is updated on a platform that has no knowledge of those facets and deletes them when a file is updated / replaced ... then this client attempts to pull down the data, look for the facet - now missing, what to set the permissions to?

Your issue might potentially be solved by setting your permissions to the correct requirements for your use.

This being said, the official Git documentation does not specifically mandate exact file and directory permissions for the .git directory, but it does provide some guidelines regarding the security of repository data. Git's focus is primarily on functionality and data integrity, but the recommended permissions are aligned with keeping repository data private and secure.

Git Documentation on Permissions:

  • Directory permissions: The .git directory is often expected to be private. This aligns with the idea that only the user who owns the repository should have access to the internal files.
    • While Git does not explicitly call for 0700 directories, it is common practice to use this setting to restrict access to the repository’s internal data.
    • This is this applications default as per the documentation already provided
  • File permissions: Git's repository files (objects, refs, and configuration files) should be restricted from unauthorized access, aligning with the use of 0600 for the .git folder files. Again, while this isn't explicitly required by Git, it ensures privacy and integrity of the repository.
    • This is this applications default as per the documentation already provided

If you are having issues with .git repositories, I would look at your workflow(s) and your data tree and set your permissions in alignment with the the Git documentation and how you access / use your data on your local filesystem.

leonbottou commented

After checking, Git only stores an execute bit for each file under version control. This is the permission that causes my problems. For instance, when git believes that a file has the execute bit off, and OneDrive restores it with the execute bit on, Git thinks that the file has been modified, include it in a next commit, and sometimes creates a history fork...

Turns out git has a pre-repository config option for avoiding this :

$ git config set core.filemode false

which means that it is not going to rely on the file's execute permission bit to determine its internal execute permission bit. The internal execute permission bit can still be set or reset with

$ git update-index --chmod=[+x|-x]  <filename>

Anyway, this solves my immediate problem.

abraunegg commented

Glad you sorted your issue with git

OneDrive restores it with the execute bit on

This client , by default does not set the execute bit on.

If the Microsoft OneDrive platform (post upload) is doing that - that is an API bug that I cannot solve.

When files are downloaded they are reset with the default permissions previously provided and as documented - unless you change this by your application configuration , or if you are using platforms like OMV that change the defaults , then the execute bit should not be set and will not be set by this application.

abraunegg commented

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.