Hi all,
has anyone an idea whats wrong here or why Syncthing wants to change the file?
It seems to be exactly the same file (= it is for sure, because it is copied with rsync).
Shouldn’t Syncthing just update the DB (it is rw) because the file doesn’t needs to be changed?
Setup:
See screenshots for details.
Thanks and best regards Robert
The permissions differ - do you have ignore permissions set?
Hi Simon,
yes, this is set.
Best regards Robert
Pity, hoped this one would be easy 
Can you hover over the error message (read-only file system), there will be a little more info. Or you could enable model debug logging (actions->logs) and pause and resume the folder and post the logs here.
I suspect we still overwrite the mtime even if it matches, which causes this.
@imsodin The error message while hovering is
finisher: dst create: open 01/26/Jana-Sophie-Fruehstueck/original/mp4/20180126-06-44-53-Jana-Sophie-Fruehstueck-26.mp4.tmp read-only filesystem
Logs with Debug switch (shortened for file relevant entries):
2018-08-09 14:16:36 syncthing v0.14.49 “Dysprosium Dragonfly” (go1.10.3 linux-amd64) deb@build.syncthing.net 2018-07-10 15:40:06 UTC [noupgrade] 2018-08-09 14:16:36 My ID: 12345678 2018-08-09 14:16:37 Single thread SHA256 performance is 462 MB/s using minio/sha256-simd (403 MB/s using crypto/sha256). 2018-08-09 14:16:38 Hashing performance is 383.19 MB/s 2018-08-09 14:16:38 Ready to synchronize “video-2018” (grzpf-owxvw) (sendreceive) … 2018-08-09 19:53:46 sendreceive/grzpf-owxvw@0xc420a20a00 parent not missing 01/26/Jana-Sophie-Fruehstueck/original/mp4/20180126-06-44-53-Jana-Sophie-Fruehstueck-26.mp4 2018-08-09 19:53:46 sendreceive/grzpf-owxvw@0xc420a20a00 need file 01/26/Jana-Sophie-Fruehstueck/original/mp4/20180126-06-44-53-Jana-Sophie-Fruehstueck-26.mp4; copy 1219, reused 0 2018-08-09 19:53:46 sendreceive/grzpf-owxvw@0xc420a20a00 closing 01/26/Jana-Sophie-Fruehstueck/original/mp4/20180126-06-44-53-Jana-Sophie-Fruehstueck-26.mp4 2018-08-09 19:53:46 progress emitter: deregistering grzpf-owxvw 01/26/Jana-Sophie-Fruehstueck/original/mp4/20180126-06-44-53-Jana-Sophie-Fruehstueck-26.mp4 … 2018-08-09 19:53:46 sendreceive/grzpf-owxvw@0xc420a20a00 changed 32 2018-08-09 19:53:46 Folder “video-2018” (grzpf-owxvw) isn’t making sync progress - retrying in 1m0s. 2018-08-09 19:53:46 progress emitter: bytes completed for grzpf-owxvw: 0 2018-08-09 19:53:46 model@0xc42021a480 NeedSize(“grzpf-owxvw”): {32 0 0 0 10487570558 0 []} 2018-08-09 19:53:46 model@0xc42021a480 Completion(ABCDEF, “grzpf-owxvw”): 100.000000 (0 / 22929610149 = 0.000000)
Best regards Robert
The error message shows that the file is going through the copier, it’s not taking the shortcut (which it should if the content is identical). The logs however do not show the relevant lines, everything looks fine in there. For example there must be at least a line containing Puller (folder “video-2018” (grzpf-owxvw), file 01/26/Jana-Sophie-Fruehstueck/original/mp4/20180126-06-44-53-Jana-Sophie-Fruehstueck-26.mp4.tmp): finisher: dst create: open 01/26/Jana-Sophie-Fruehstueck/original/mp4/20180126-06-44-53-Jana-Sophie-Fruehstueck-26.mp4.tmp read-only filesystem. You can upload it unshortened somewhere, we will take care of finding the relevant stuff.
Maybe one of the folders has large blocks enabled?
@DrSchnagels Bingo. But how to fix this / how to start a complete rehash?
@imsodin I will provide a new (full) log after I’ve checked the large blocks thing.
Not necessary, now that @DrSchnagels hit the lottery jackpot followup on that first. As you are on a read-only fs you will need to readd those folders (or if it’s all folders, delete the database). Otherwise you could have touched the files in question to make Syncthing rehash them. And of course enable large blocks on both devices and all folders.
Ok. Will try it.
But just for my understanding: shouldn’t be the large blocks option a kind of “replicated” configuration which is set while adding folder at a device via a invitation?
Otherwise you have to pause the new folder “fast” before scan/hash begins on the new device, then enable the option and unpause.
Additional I would suggest to add the current behavior (if my above assumption is correct) to the documentation at https://docs.syncthing.net/advanced/folder-uselargeblocks.html.
The thing is, this is only such a problem because your filesystem is read-only. And yes, it would make sense for large block to propagate to other devices, but the decision was made against for simpler implementation (after all it’s still experimental/hidden, so the user must decide purposely on activating it).
It would definitely be good, if it was written explicitly in the docs, that large blocks should be enabled on all devices for one folder or on none.
You are right, without the read only FS an kind of “Self Healing” would happen.
But if I think right, in a inefficient way. Wouldn’t Syncthing transfer the whole file(s) if the hashes aren’t matching?
Can I help to update the documentation?
Little update: with the option enable or disable large blocks on all blocks I decided to try the enabled one. So far so good. Now I have 4 nodes, two running Linux and 2 Android.
The thing is: on the android devices, the checkbox for large blocks is no longer ticked. Now I am not sure if this is a UI Bug or if it is really not enabled.
But if it is really disabled, the nodes will never come in sync, right? They are in Sync. So it seems to be a visual bug.
Best regards Robert
They aren’t necessarily getting out of sync if large blocks isn’t enabled everywhere. And if the checkbox isn’t ticked, the option isn’t activated. For me the tick stays, so this isn’t a general android problem. Try again and if it really disappears, something is wrong. No idea what or what to look at though.
Regarding docs: Sure you are very welcome to adjust the documentation and file a PR.
I need to check this, but probably you are right about android losing the largeBlock flag on performing folder config tasks through the android UI.
What, why? Shouldn’t that be handled by the android app (anyone handling the rest api) by getting the config, modifying whatever needs modifying and then posting it back - thus unknown/unhandled config elements just stay the way they are?
The deserialization looses fields that are not defined, exactly like Go.
Argh, ok. So adding new fields to the config is “more breaking” than I thought. We have so many wrappers, I believe we really need to coordinate/inform about config/rest api changes better…
