MEGAsync icon indicating copy to clipboard operation
MEGAsync copied to clipboard

File permissions are changed when syncing between two machines

Open DanHam opened this issue 3 years ago • 7 comments

When syncing files between two machines the file permissions are not preserved.

Steps to reproduce:

  1. On Host A:

    Create and set permissions on some files:

    mkdir ${HOME}/test-mega
    touch ${HOME}/test-mega/normalFile
    touch ${HOME}/test-mega/execFile
    chmod u+x ${HOME}/test-mega/execFile
    
  2. On Host A:

    Create a new sync via the MEGAsync GUI:

    Settings -> Syncs Click on Add button Set Local folder to $HOME/test-mega Set MEGA folder to test-mega (Create new test-mega folder on Cloud Drive) Click on Apply button

  3. On Host B:

    Create a new sync via the MEGAsync GUI (sync with the new folder we just created):

    Settings -> Syncs Click on Add button Set Local folder to $HOME/test-mega Set MEGA folder to test-mega Click on Apply button

  4. Listing the permissions on both hosts shows that the file permissions are different:

    On Host A:

    ls -l ${HOME}/test-mega/
    -rwxr--r-- 1 dan dan    0 Apr 29 14:44 execFile
    -rw-r--r-- 1 dan dan    0 Apr 29 14:59 normalFile
    

    On Host B:

    ls -l ${HOME}/test-mega/
    -rw------- 1 dan dan    0 Apr 29 14:44 execFile
    -rw------- 1 dan dan    0 Apr 29 14:59 normalFile
    

The change in permissions means that it is impossible to sync a Git repository containing executable files between devices. Since Git tracks file permissions, the files on one machine will always show as modified no matter what steps are taken to try and remedy the issue.

DanHam avatar Apr 29 '21 14:04 DanHam

MEGAsync currently does not carry file permissions when synching files, it establishes 600 by default for files and 700 for folders You can adjust the default permissions in Settings->Syncs tab -> Permissions. There you give execution permission to the owner of the file, and that will be applied to all new files created by MEGAsync.

polmr avatar May 03 '21 06:05 polmr

That seems like a recent change. I was able to sync a git repository before without these permission issues.

rafael-brandao avatar Jun 17 '21 10:06 rafael-brandao

While in Linux Mint 20.2:

  1. I stopped the synchronization between Mega and my two computers that are linked.
  2. Then I deleted my Mega synchronized folders in both computers.
  3. Then I cleaned up my Mega cloud space through the web (some files and folder, not all my data).
  4. Then I re-linked my Mega in my two computers.
  5. Then ALL FILES, INCLUDING .TXT, .C, .ZIP, ETC, IN MY TWO COMPUTERS NOW APPEAR AS EXECUTABLES, EVEN THE DIRECTORIES !!!

This is an example:

drwxrwxrwx  9 fjrg76 fjrg76    4096 sep 25 21:20 ./
drwxrwxrwx 16 fjrg76 fjrg76    4096 ago 23 19:50 ../
drwxrwxrwx  2 fjrg76 fjrg76    4096 ago 23 20:24 2021-1_tmp/
drwxrwxrwx  4 fjrg76 fjrg76    4096 sep 25 21:20 2022-1_Sol/
drwxrwxrwx  2 fjrg76 fjrg76    4096 sep 22 23:01 2022-1_sources/
-rwxrwxrwx  1 fjrg76 fjrg76    6984 sep 22 23:03 2022-1_sources.zip*
-rwxrwxrwx  1 fjrg76 fjrg76    1037 mar 16  2021 counting_para_terminar.c*
-rwxrwxrwx  1 fjrg76 fjrg76    1486 feb 17  2020 counting_solved.c*
-rwxrwxrwx  1 fjrg76 fjrg76    1448 oct 15  2020 countingsort_para_terminar_2021-1.c*
-rwxrwxrwx  1 fjrg76 fjrg76 1064327 sep 22 23:13 P3_2022-1_1.0.pdf*
-rwxrwxrwx  1 fjrg76 fjrg76   17411 sep 22 23:13 P3.adoc*
-rwxrwxrwx  1 fjrg76 fjrg76    8584 oct 15  2020 salida.out*

What did you do guys? Mega used to work like a charm.

eda1-fiunam avatar Dec 02 '21 18:12 eda1-fiunam

I have the same issue. MEGA is not alone, but nextcloud too. git statuscan see the changed permission of the file "run.sh".

Try to run git config --global core.filemode false for all git projects or git config core.filemode false for individual project. That means git can ignore file permissions. But not good idea.


I tried to change MEGA sync -> Settings-> Syncs tab -> Permissions, but it creates new files with the same permission on other device.

  1. Device:
-rwxr-xr-x 1 zesko zesko   permissiontest.sh       # is executable
-rw-r--r-- 1 zesko zesko   non-permissiontest.sh  # is not executable

sync to 2. Device:

-rwx------ 1 zesko zesko   permissiontest.sh         # is executable
-rwx------ 1 zesko zesko   non-permissiontest.sh  # is executable

Why not 1:1 sync file permission for linux. But Dropbox can do.

Zesko avatar Jan 07 '22 09:01 Zesko

The core issue here is that MEGA does NOT support:

  • Syncing file permissions between machines.
  • Syncing permission to/from MEGA Cloud Drive.

MEGA can only apply ONE DEFAULT set of permissions (set in Settings->Syncs tab -> Permissions) to a file when it it is created - either through a sync operation between machines or when it is restored from Cloud Drive.

This makes MEGA unsuitable for my purposes - I have now closed down my MEGA account and no longer use it.

I switched to using Vorta/Borg for backups and Syncthing for synchronising files between various machines.

I configured Vorta to back up to rsync.net (cloud based storage) as I already had an rsync.net account. rsync.net even give users a special discounted rate when using their service for borg backups.

However, BorgBase also provide very reasonably priced storage for your Borg backups.

DanHam avatar Jan 23 '22 18:01 DanHam

If MEGA developers think that syncing file permission is not easy, because you sync file between Windows, Linux and MacOS. All 3 operating systems have different file systems and permissions.

Okay, then let me suggest a new feature how to solve it better:

  1. Create a new permissions list as an invisible or hidden file with YAML format. (It is only used for synchronizing file permissions.)
  2. MEGAsync scans and checks all files with their permissions, if they are changed.
  3. MEGAsync writes permission of changed file 1 in the permissions list that is changed too (Of course with a timestamp).
  4. Another device using MEGAsync to check it and will change permission of the same file 1. (It looks like how permission sync works)

How does YAML format look like from the permission list:

file: {FILE NAME}
  unix: {PERMISSION for Unix only}  #  If no permission, then using default permission
  windows: {permission for Windows}
  macos: {permission for macOS}

# Example 1
file: "test.sh"
  unix: "-rwxr-xr-x"
  windows: "unknown"
  macos: "unknown"

# Example 2
file:  "run.sh"
  unix: "-rwxr----x"
  windows: "unknown"
  macos: "unknown"

...

Is my idea possible for MEGA developers? Does that help?

Zesko avatar Jan 23 '22 19:01 Zesko

@Zesko That's a good idea. This is the approach taken other file synchronization utils - only they use a slightly more compact and sync friendly format than YAML for storing the file names and permissions.

DanHam avatar Jan 23 '22 20:01 DanHam

Dirty workarounds (dry-run replacing chmod u+x with realpath). This will search on the current dir (and it's subdirs) for executable (using file in the first alternative) files with permissions set to 600.

Using file:

find . -perm 600 -type f -execdir sh -c 'file -b "'{}'" | grep -q executable' \; -execdir realpath "{}" \; -execdir chmod +x "{}" + # in this case, showing with realpath AND changing with chmod

Using shebangs:

find . -perm 600 -type f -execdir awk 'FNR == 1 && /^#!.*(bash|python|perl)/ {err = 1} END {exit !err}' {} \; -execdir chmod u+x {} +

Using filename extension:

find . -perm 600 -type f -regex ".*\.\(sh\|py\|pl\)"  -exec chmod u+x {} \;

To exclude .debris dir, if you are on ~/MEGA, add -not -path "./.debris/*" after -type f.

Other ideas might be using inotifywait, setfacl or chacl.

Planning my way out if it is not fixed soon (duplicated here), maybe to Syncthing. Also because of the symlinks issue.

pabloab avatar Oct 06 '22 06:10 pabloab