rupa

Same here. I also couldn't sync on my lan since my sync service is in a docker container. Switched the container to use host networking and at least sync on lan works.

That is unfortunate when there is a large directory tree. Guess I'll have to work around it. Sent from my Nexus 6 using Tapatalk

I have a shared folder with lots of directories in it (each directory has files in them). When I connect the folder to my Android device with selective sync turned on, I can selectively sync files just fine. However, *every* directory that exists in the share is created on the Android. I would expect that only the dues that have synced files would be created. Sent from my Nexus 6 using Tapatalk

I started the update to 2.0.93 from (.95) thinking this would take the normal 1min max. Little did I know it would take around 45min. The culprit was that there was a scan of all active volumes for .sync folders. Holy cow. My backup volume that uses dirvish to backup unix(ish) systems was included in that scan. dirvish uses hardlinks to minimize disk usage but ends up with TONs of hard links. I don't want to count the total number, but it is in the millions I'm sure. Autoscanning the full set of volumes on a NAS is probably NOT a good idea guys!

I could find no way to do this from the web gui. You can do it by: 1) Generate a secret from the commandline: $ /usr/local/bittorrentsync/bin/btsync --generate-secret 2) Click on 'Manual Connection' and then paste the secret generated. You'll then select the folder for that. The folder will be setup as a 1.4 folder. Alternatively, install the old version of btsync on another system (eg: old windows machine) and create the shared folder there. Then copy the secret and use that secret as described above to manually connect. There is no conversion path to 2.0 at this point. Dunno if that is planned. You can always unsync and resync at a future date to go to 2.0.

And here - 1511+, it never syncs v2.0 shares. However, it syncs fine for 1.4 shares. Even new 1.4 shares created with the older windows client.

The scenario: I have a Synology NAS which stores many extended attributes in a extra directory called '@eaDir'. I normally hide this directory by adding @eaDir to the .sync/IgnoreList. This is syncing to my Android phone. So, on the synology we see: directory/File.mp3 directory/@eaDir/File.mp3/01APIC_00.png Any action that removes the directory through normal (NAS, eg: smb, web) means removes the corresponding extended attribute. Deleting the file through rm or unlink however leaves the fake EA out there. So, I add @eaDir IgnoreList. No extra @eaDir crap gets synced to the Android. However, when I delete stuff, the @eaDir crap is left alone. Even when I delete the containing directory, the @eaDir is left. So then the Android gets the directory synced back. Of course, on the Android the directory is empty. The only way I can 'fix' it is to login to the NAS and delete the directory from there. Anyone dealing with the same issue? Suggestion: When removing a directory, if there are ONLY elements in that directory that are in the ignore list, remove them and then the directory on the synology. I realize this may be undesirable, so maybe the behavior should be optional on a per-share basis with a way to set a default system wide. Thoughts?

Yes, photoshop is the app in which I've seen this behavior.

This hasn't helped me. I have the exact same issue. All the computers are synced with ntp. Multiple PCs, 1 linux server.