Wishlist (Archive)


Recommended Posts

  • Replies 811
  • Created
  • Last Reply

It would be nice if the Linux (and Android) client used the O_NOATIME flag when opening files just to check them. The documentation (from "man 2 open") reads thusly:

O_NOATIME (Since Linux 2.6.8)

Do not update the file last access time (st_atime in the inode)

when the file is read(2). This flag is intended for use by

indexing or backup programs, where its use can significantly

reduce the amount of disk activity. This flag may not be effec‐

tive on all file systems. One example is NFS, where the server

maintains the access time.

I think btsync is very similar to the intended use case for this flag!

Link to post
Share on other sites

Documentation of the format of .SyncIgnore, and potential enhacements if what I outline below does not exist.

I ask because I want to sync part of a directory ( a set of sub folders and files ) and the logic I see is that I would first exclude everything, and then include (recursively) only the folders I want to sync. This requires both "include" and "exclude" logic as well as recursion and wildcards.

My use case is I want to sync 25 folders in "home/peterk" but nothing else out of the dynamic 100 or so folders and files in there, and it is impractical to have a separate "secret" and maintain it for each one, or maintain .SyncIgnore in what may be a locally dynamic collection of files and folders to be ignored.

ie: does "folder/**/*.xxx" mean recursive ignoring as in .gitignore ?

is there an inversion descriptor meaning include an item or items instead of exclude ?

does a .SyncIgnore in a subfolder to a "secret" act on all it's children ?

if so does it "subclass" (add includeds and remove excludeds from the .SyncIgnore state in the parent folder ?)

( there seems to be some evolution toward a common-standard idea of thes types of descriptors - ie: ruby filelist, .gitignore and the like )

The fuller logic would be extremely desirable, and could be added to the GUI ( sub folder selection via browse tree menu ) for a secret later.

Whatever the format of course, it needs to be fully documented in the user guide.


Link to post
Share on other sites

Just got the app for iOS, and I love the sync for camera roll! I understand that is about all you can do with the app as Apple doesn't allow much else. I would like to see back ground syncing though so I can exit the app and do other things. If you are worried about battery life, only enable background sync when plugged in, like how iCloud works.

Link to post
Share on other sites

+1 for write-only connections

please add this!

I have a server should server incoming data to multiple clients. The clients have huge amount of storage. The server does not. I can only hold data worth around 10 days in storage. If delete at serverside, the files at the clients should not be moved if possible

Link to post
Share on other sites

Only made it through about 14 pages of wishlist before I decided to just go ahead and post, so this has probably been suggested. (There were a couple that were close in those pages even.)

I've been doing some testing on the versioning, since that was the biggest hold up for me from using it on a broader scale and it seems to be catching most of what I throw at it. (Near instantaneous saves on different computers were the only thing that seemed to get by BT Sync, since I believe it operates by polling the files.)

The main thing I would like to see related to this though is something in the history to note the creation of a new version file and a persistant pop-up (rather than one which fades away) that a new version was created of a file (the latter could have a few settings potentially-- no pop up, regular pop up, or persistant pop up). That will allow me to go in and resolve the conflict rather than having to check the sync folder every once in awhile. For the instantaneous save thing, if a time stamped change is within the margin of error (3 seconds or whatever the polling rate is), it would be nice if that generated a version on whichever computer is receiving the file too.

Link to post
Share on other sites

Sorry if this has already been brought up, but this list is really too long to scan. As suggested above an issue tracker might solve this.


Anyway, I have a suggestion to change the way versioning is handled. At the moment the implementation is such that older versions of a file can be found on all clients except the one where the change is done. This behaviour is not what most people (especially non-programmers) expect. By also synchronising the folder with the versions all clients have access to all the versions. I think that is exactly what a simple user expects.

Link to post
Share on other sites


I just installed BitTorrent Sync on my Ubuntu Server.

I am protecting the BitTorrent Sync Webpage with a username and password.

But it is using http and not https, so the username and password is not encrypted.

Is there any easy way to switch the BitTorrent Sync Website to https?

Any how to for this ?

Or can you maybe just switch to https in the next release please ?

Link to post
Share on other sites

Bittorrent Sync is fantastic. You have done a amazing job and i think Bittorrent Sync will change data storage forever. But there are 2 things I miss that exist in many cloud storage systems.

1. Dashboard

It would be great to be able to access and upload files with a web interface. The case when this would be great is when you are on a friends or on a work computer and you do not want to share your secret. For my purposes it is enough if this feature only exist on the Linux client. The Linux client already have a web interface to handle secrets so the step to have a dashboard can't be to huge.

I have successfully set up Barracuda drive and Bittorrent Sync on my own server but it is a dirty setup. I read about someone that used Ownclouds dashboard with Bittorrent Sync, so at least one person more than me are interested i this feature.

2. True versioning

This is a big wish but it would really be great. I know there is versioning one sense in Bittorrent Sync, you can visit the archive and trash folder and try to get your data back. But these folders does not contain all changes made in the system and the interface to handling "versions" is not smooth. As a steppingstone to "true versioning" it would be great to only have versioning on the Linux client. All changes have to be synced to this Linux client with versioning activated(If a node is offline and 5 changes are done all 5 changes have to be stored in that node until the changes can be transferred to at least one node with versioning activated if there are one or more nodes with versioning activated in the system). If there is more then one versioning node activated the versioning nodes have to share changes with each other. To manage versioning and conflicts it would be great with a web interface on the Linux client.

Think of all company and private projects out there that could use this and it will totally remove the need for a external backup system.

Link to post
Share on other sites

Hey there.

While browsing the new "Sync Hacks" forum, an idea came to my mind.

If it can be done, would be pretty awesome.

The thing is: Provide a binary which runs on VMware ESXi 5.x environments.

I currently run a single VMware ESXi (free edition) hosting a couple of VMs. Using a NAS here is way to expensive in terms of providing enough IOPS, so I stick to an internal RAID controller wich does RAID10 with 4 SATA-HDDs. I know, it's kind of a playground environment and far away from supported configuration, but that's not as unusual for geeky guys :).

It would be pretty awesome if I could make the ESX do regular backups automatically to any cheap 2TB NAS for $100 just by btsync. My current backup setup is driven by ESXs interl exporting feature "copy virtual hdd to attached NFS storage". But that's one of to major disadvantages. I can either convert the virtual HDDs from regular to "2tb split", which is nice in terms of backup space usage but completely eliminates any offsite synchronization due to internal block shifts. Or I could backup the files "as they are", which would allow for rsync-like offsite mirrors but needs an awefull lot of storage space because the NFS way blows the spares away.

So the thing is: btsync here would be just great for both, backupping to locally attached storage and offsite backups.

Currently the linux builds die teling me "terminate called after throwing an instance of 'std::length_error' what(): basic_string::assign".

Kind regards,


+1 for this. I too am encountering the std::length_error.

Would love for sync to work nativly on the ESX machine

Link to post
Share on other sites

I would absolutely love to create a read-only key for a sub-folder of something I already have shared. This is apparently known as "nested shares".

I'd love to have a timed "pause" feature, so that if I have a Skype call and the connection sucks, I can pause for an hour, and have BTSync resume automatically. Otherwise I'm guaranteed to only remember the next day, when my files aren't synced.

I'd like to be able to create an HTTP URL to a file or a folder, a cheap/free one where my computer must be online and properly configured (and does all the sending), and maybe an expensive one where BitTorrent servers store/send the file/folder.

Finally, it would be really cool if a massively cut down version of the BTSync protocol were implemented in pure HTML5/Javascript, so that it would be possible to "download" a file from a number of peers in exactly the same way as the full BTSync client would, just by pasting the secret code.

Link to post
Share on other sites

display the found peers with same secret maybe in the Folders properties page?

This would make troubleshooting the connections easier.

maybe like this:

D:\myFolder -> properties -> Tab "peers"

PeerName - IP:Port - found via: Tracker/DHT/LAN/.. - has Read/ReadWrite Secret - lastconnectTime - lastErrorTime - ...

maybe even keep a history of peers that have ever synced



Link to post
Share on other sites

The OS X/iOS application deskconnect (http://www.deskconnect.com) allows the user to transfer files, text, clipboard contents, and the current browser tab between Macs and iOS devices through an icon on the menu bar.

Adding a similar feature (small text, clipboard contents, maybe current browser tab) to Bittorrent Sync would be even more valuable since the data would be sent securely.

Link to post
Share on other sites

For extended purposes, the initiation of a sync is too slow.

When new files are added or changed/renamed, I observe a time delay

between 10 and 18 sec before the sync starts.

No idea about the reason for this, and it is basically fine, so I would simply add:

A tiny API, some CLI operations or whatever, that enables triggering

the transmission of a file or message immediately, without

having to wait for the synchronization to be initiated the normal way.

This is the missing piece to write distributed applications with fast message passing.

cheers - chris

Link to post
Share on other sites

A daemonized version for all systems (where possible), including the webui OR make desktop versions headless capable with commandline switches and a webui.


OS X specific wish (minor bug?): Closing of the window (Open Bittorrent Sync) with cmd+x would be great.

Link to post
Share on other sites

In my opinion, I'd be great if there is a force sync option for the application. In case we want sync all data backup from main server to other backup servers at different locations using one way synchronize (using read only secret). Any changes of data at main server will be full sync to backup servers, when data in backup servers has accidental delete, edit... then it will be full sync again data from main server (all data in backup servers always be the same data at main server).

Hope BitTorrent Sync Team will update this option in the next release soon, it will be very very useful as the Torrent Sync app,

Thanks BitTorrent Sync Team for your great work!

Link to post
Share on other sites


This topic is now archived and is closed to further replies.

This topic is now closed to further replies.