diamondsw

Apps using significant energy: Resilio Sync Nothing about Resilio Sync should require more than a recompile. Especially since it already runs on ARM on Linux, so there aren't any hidden instruction set or library issues.

Resilio MIA for 7 months, Helen MIA for 3 months; ridiculous doesn't begin to cover this. I want a detailed technical explanation for this not being possible in v2.5.x, or I'm simply chalking it up to customer-hostile laziness and incompetence.

While this is aesthetic and not functional, it does mean that anyone who runs dark mode has had a big old glaring white spot on their menubar for *four months*. No, I don't care if you have an update in the pipe - Resilio is clearly still pushing updates to version 2.5, and they can fix the *** icon. This is not an intractable architectural issue; it's drawing an icon on the screen.

I assume you're referring to x64 at https://help.getsync.com/hc/en-us/articles/206664850-Synology (nothing on the page refers to glibc version or dependencies). If so, that's what I already have installed. Or is there a reason to install a chip-specific version (for instance, the DS1817+ is based on an Intel Atom C2538, i.e. avoton)? EDIT: Swapping in the "Avoton" file for the original "x64" file appears to have done the trick. I originally went straight to x64 since I knew it was a 64-bit Intel platform, and the various chip names meant nothing to me at the time.

Here's what I did: Stopped Resilio Sync. Rotated /usr/local/resiliosync/var/sync.log (which had grown to 66MB in a couple days). Started Resilio Sync, and allowed it to discover peers. Created a test file via 'touch /volume1/Apps/Sync/General/test-file' (General is one of my synced folders). Confirmed nothing appeared on other hosts. Stopped Resilio Sync. Made a copy of the log (attached as 'sync-1.log'); rotated logfile. Started Resilio Sync, allowed it to discover peers and transfer the test file, which is does on initial launch. Stopped Resilio Sync. Made a copy of the log (attached as 'sync-2.log'); rotated logfile. Verified ACL/permission access: jochs@Synology ~ $ sudo synoacltool -get-perm /volume1/Apps/Sync/General/ rslsync ACL version: 1 Archive: is_inherit,is_support_ACL Owner: [jochs(user)] --------------------- [0] user:jochs:allow:rwxpdDaARWc--:fd-- (level:2) [1] user:rslsync:allow:rwxpdDaARWc--:fd-- (level:2) [2] user:guest:allow:rwxpdDaARWc--:fd-- (level:2) [3] user:admin:allow:rwxpdDaARWc--:fd-- (level:2) [4] user:transmission:allow:rwxpdDaARWc--:fd-- (level:2) ==================================================== User/Group: [rslsync/users,administrators,sc-download,rslsync] Final permission: [rwxpdDaARWc--] The first time Sync sees the test file is in 'sync-2.log', line 1744 (i.e., only after starting fresh and scanning its folders). I can provide whatever additional logs, details, and tests are needed.

Will it fix the ongoing "Sync doesn't detect changes" issue?

Running into this exact same issue with a Synology DS1817+ and DSM 6.1.1-15101 Update 4, and Resilio Sync Pro 2.4.5 (903). None of the causes above apply, yet changes are not being detected and synced out. Only on restarting Sync does it see any changes. Like others, incoming changes have no problem; this is Sync not getting filesystem change notifications. I'm moving files directly via 'mv' on an SSH session. As direct as it gets. '/lib/libc.so.6' yields 'GNU C Library (crosstool-NG 1.20.0) stable release version 2.20-2014.11'. So just 17 versions past 2.3. I have a several dozen small text files in Sync. A horribly underpowered Drobo 5N never broke a sweat. Meanwhile, Transmission manages to detect file changes immediately and load torrents from its watch folder. Sync does not see changes right under its nose. This is a Sync bug, and extremely aggravating.

I've been fighting with this particular bug, and was at first led astray by other threads that made it seem like simple HTML rewriting would do the trick - no such luck in client-executed Javascript. I assume this is all compiled into the Linux executable, as I can't locate anything on disk to edit; I can only make these changes on-the-fly in my browser. If anyone knows a way I can make this change permanent, please let me know! [EDIT: Found a way via nginx subs_filter!] This bug is especially offensive as it is going out of its way to create the bad behavior - doing nothing would have worked fine. Doubly-offensive in that it was reported eight months ago and never fixed despite how simple it is. In the v2.0 webui.js I'm looking at, start at line 1113 and delete the following lines: var urlBase = "";var guiBase = urlBase + "/gui/";var proxyBase = urlBase + "/proxy";Yes, delete entirely. None of this should exist. guiBase is causing the bug, proxyBase is completely unused, and urlBase is only used for guiBase/proxyBase, which will shortly be unnecessary. Then delete the references to guiBase on lines 1136 and 1156 - they're unnecessary. They should now look like this: 1136: url: "?" + params.join('&'),1156: url: "token.html?t=" + Date.now(),That's it - removing code fixes this bug. Here's my nginx configuration that rewrites the JavaScript on the fly: location /proxy/btsync/ { proxy_pass http://nas:8888/gui/; subs_filter_types text/javascript; subs_filter "/gui/" ""; }