Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spurious need to "revert" nonexistent changes with Receive Only folder on Android #5777

Closed
calmh opened this issue Jun 11, 2019 · 2 comments

Comments

Projects
None yet
3 participants
@calmh
Copy link
Member

commented Jun 11, 2019

In https://forum.syncthing.net/t/ignore-permissions-different-mtimes-on-android-sdcard/13342, Richard says

I’m running the 1.1.4 version of syncthing from master on github (v1.1.4+34-g5541697d compiled locally - not the pre compiled version). One machine is a Linux desktop.

I’m sharing with Android on external, FAT formatted, SD card. The syncthing version is Catfriend’s syncthing fork, running 1.1.3.

Android has Receive Only and Ignore Permissions set.

Each time syncthing is restarted on both machines, syncthing on the Linux machine reports that syncing with the Android device has stalled. On the Android device I look in the Web GUI section and have to press “Revert Local Changes” (even though nothing has changed).

The problem is fixed if I set Ignore Permissions on the Linux box, too.

Some questions:

Is this normal behaviour? That is, is it normal that if both Receive Only and Ignore Permissions are set on the Android device, permission differences on the Android device show up as local changes that have to be reverted?

Are these two settings mutually exclusive?

If I set ignore permissions on a folder on one machine, do I have to set it on all machines?

It would be nice if I could leave permissions not ignored on the Linux box, so that permissions would be propagated correctly on other platforms that support permissions.

Apologies if I’m missing something obvious.

Thank you once again for this beautiful and immensely useful program.


This turns out to look very much like our mtime faking doens't work and some debugging ensues.

@calmh calmh closed this in b7c70a9 Jun 11, 2019

@calmh calmh added this to the v1.2.0 milestone Jun 11, 2019

@calmh calmh added the bug label Jun 11, 2019

@pgnd

This comment has been minimized.

Copy link

commented Jul 10, 2019

@calmh I'm seeing this^^ behavior. I've upgraded server-side (linux) to 1.2.0 release, but client, for now, is still @ 1.1.4.

Does this mtime fix require 1.2.0 in client as well?

@AudriusButkevicius

This comment has been minimized.

Copy link
Member

commented Jul 10, 2019

Yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.