RomanZ

@colinabroad Thanks for the logs - it will take some time to analyze the results @BrianR549 As I understand your issue is not purely cosmetic - the Excel actually complaints that it can't save the file, right? If yes - we'll need Process Monitor logs first of all. You may use address suggested by @colinabroad or mail us at syncapp@bittorrent.com

Not yet! Though we are working on it, will update when get some news.

What about range used for VPN channel? BTW, you can try to disable tracker and LAN discovery and leave predefined hosts only.

@jdrch Actually if you don't have 2 versions or don't play with x86/x64 installations - it should keep only one. Did the reinstallation help or you still encounter issue?

@b0rman If Sync has access to multiple NICs, it always prefers "local" connection. It determines local IPs according to RFC1918. What are the IP ranges you use in LAN and for VPN?

@Ahmed Badr, Please try also scanning same QR with Barcode scanner and let me know if it worked for you. Also, what is the number of ticket you receive in response of your feedback?

@pinitrius Well, actually it should be already fixed in 1.4. Are you willing to send us debug logs so we can see what happens in your environment? @TheCatLady I'm somewhat lost in your scenario. Could you please describe step-by-step what was happening on each computer so I can understand at least if it was a design behavior or you encountered some bug?

@thinkon Thanks for reporting. We'll try to reproduce in lab and fix.

@acffordyce973 Could you provide couple of screenshots? As I understand you got a folder on Android Nexus tablet, share it it, open webUI of your computer's Sync on Nexus, paste the link there and got your "Unknown error"?

Which version of sync do you use? By default webui listens only loopback interfaces. So you'll need to start sync with "--webui.listen <IP:port>" switch to force webui to bind to necessary interface. See here for more details.

Sync does not like case-sensitive files and it will treat them separately. If you've got a "File" on one peer and "FILE on another, they will be synced into "File.conflict" and "FILE.conflict" resulting files on 2 peers respectively.

@demani You can do any. Direct copy and add should also work find - Sync won't re-transfer files. Though, you can't change the folder from RW to RO, so add it as RO from beginning.

@klues I see that you've mailed to our support - please follow instructions in order to resolve issue.

@lupus That's not good. I wonder if you can collect Process Monitor logs when issue happens and send to me?

Great! Let me know if experimental build resolves your issue.

@Faadiz Usually it is caused by connectivity issues. Please check and make sure your firewall is not blocking ports used by Sync.

The e-mail was sent to mail box bound to your account on forum, should be coming from bittorrent.com domain, sent on Nov 24 1:24 pm GMT

@xjx If the peer which uses CIFS to store sync folders uses RO keys only - there will no be "lost files" issue. The worst issue which could occur that CIFS will refuse to save files and Sync will stop syncing them to your RO peer.

Hi Frank, Usually, Sync stores all its data in storage folder. By default, it is located in ".sync" hidden subfolder next to binary. Though, it is possible to run Sync with --config parameter and specify whole config file which says where to store service files. The PPA version uses second option and keeps storage separately from binary. You can try to do the following: find where storage is, grab it, and put to the ".sync" folder, which should stay in the same directory where binary stays. You can easily find it by "settings.dat" and "sync.dat" files (though note, that you'll need to move all the files in storage). For the future - you can backup storage folder AND all the .sync subfolders (each folder you Sync has one).

@ninja6o4 If you want to help us with the issue happening in your setup - let me know, we'll do our best to debug and fix it.

@syncobit Files are get archived upon deletion only on Desktop Sync. As mobile devices have very limited space, once you delete file on Desktop - it will be really deleted on mobile, not moved to Archive.

@Ravidlow It would be highly inconvenient for users to review each folders settings once you create it: not all of the users need that. Also nor tracker server neither relay server "register" incoming IDs. They keep it in memory while at least one peer stays connected. Though we acknowledge that security-aware users may want Sync never connect to external servers - and did appropriate improvement in 1.4. There is a special set of advanced preferences in 1.4: folder_defaults.delete_to_trash folder_defaults.known_hosts folder_defaults.use_dht folder_defaults.use_lan_broadcast folder_defaults.use_relay folder_defaults.use_tracker They are applied to the folder right at the moment of creation so if you disable connection to relay / tracker / DHT - they are disabled from the very moment of folder creation. So I can advise to upgrade to 1.4 to use these settings. If there is some serious issue preventing you from upgrading - please let me know, it might be either already resolved with latest build or I'll help you to deal with it.

@chairman.faust The message in log does not indicate the error, it says "no error". Could you please provide debug logs?

@scottbakertemp M3U playlist is actually text file and is human-readable. It may contain both absolute and relative paths. At the end of day, iOS still have its filesystem (though does not show it to user) and if your M3U contains relative paths and files are stored in same relative position (which means at least they should stay in the same app on iOS) - there are good chances that player supporting M3U can play it.

@mertzi No, x64 bit version was introduced with the release of 1.4.