mackup
mackup copied to clipboard
lra
Why mackup change files' permission
I have some executable script sync with mackup, when synced, these files will not be executed
If you sync a folder and not the files within it, mackup does not change the files permissions. Make sure you sync a folder and not files.
My bad you are right, but it's this way because some file syncing engine and some OS mess up with the permissions (e.g. make some file executable, or world readable), and unless we find time to write specific code for each engine, the default has been to just make every folder and file read/write for the current user only.
This bites me whenever I run mackup backup. I use Mackup, zsh, oh-my-zsh Git functionality, and powerlevel10k theme. If you run into problems with gitstatus, just use:
chmod +x ~/<your cloud drive>/Mackup/.oh-my-zsh/custom/themes/powerlevel10k/gitstatus/bin/gitstatusd-*
When I copy any file (mackup backup -> file_system), their permissions totally reset to 700, and don't resore (when mackup uninstall)...
@hujianxin did this issue go away for you? I can retry with the current version, if so.
I have the same issue on macOS and Dropbox.
@lra
What is the significance of calling chmod() after copying the file or directory?
https://github.com/lra/mackup/blob/736c9975bf6f35fb52e5b14ef6cf72802356c760/mackup/utils.py#L142
I understand what I am about to propose may be inefficient, but can we call os.access() with os.R_OK, os.W_OK, and os.X_OK on the file or directory (recursively) to see what permissions the user has and set them correctly when backing up (instead of setting them to 0600 or 0700 blindly)?
os.access() will consider ACLs as well, which is a bonus.
Because the mackup backup command is rarely called, the overhead of calling os.access() should be tolerable.
@lra, I just noticed this issue is closed. Would it be possible to reopen it if you think using os.access() has some merit?
Removing this would require adding tests and testing it on all engines, because it was added to prevent errors when adding files with bad modes to synced folders (e.g. in dropbox) leading to errors and issues.
@lra could we just add a separate CLI flag to force keeping file permissions then? Users having the above problem would have a mechanism to solve it, with a remark there's no guarantee of no engine-specific errors, the rest would be unaffected.
