Wishlist (Archive)


aurika

Recommended Posts

personal Sync-server (on local -LAN-WAN) without internet.

 

What exactly do you wish for? I think it's already in place now. If you set up a btsync instance on server 1, which does not relay, etc. and you set up server 2 which syncs only to a specific host (server 1), that's exactly what you mean, right?

Link to comment
Share on other sites

I am having trouble creating a valid config file for btsync on BSD. As soon as I try to specify shared folders I get error messages. It would be nice to have a way to save the current config or display it on the screen so I can save it to a working config file.

Also, a proper way to shut down the service from the web GUI would be nice - Linux and BSD. Kiling the service seems crude and risky in case I kill it while a file is being written.

Link to comment
Share on other sites

Versioning

 

Another vote for synchronizing the SyncArchive folder so that every peer has the same versions of the same files.  As it stands now, new versions of files only appear in the archives of one's peers.  And, since the files are independently named per peer, the only way to resolve a conflict would be to hunt down the copies on all the other devices, open them all up, visually inspect them, then pick the one for the final merge. Ouch!

 

You could still use the sync event to trigger the versioning.  Rather than relying on a sequence number, maybe just use a timestamp from a common clock and append it to the name. Every version with a unique name then just gets synchronized to all peers. 

Link to comment
Share on other sites

HI,

 

I am primarily using SyncApp between my laptop and my phone as an experiment.at present. Its nice, but is a work in progress.

 

Couple of requests -

 

1. VERY IMPORTANT - In light of the problems when ALL files do not get synced (which I also have) - a method of indicating which files are NOT synced is critically needed. This is urgent else the application cannot be trusted and that is a disaster for all.

 

2. I ditto on the need to use VSS on Windows.

 

3. Also ditto only syncing those blocks that have changed - may not be possible in a light weight client but then the next point becomes very important.

 

4. IMPORTANT - Prioritisation of files or directories being selected for synced - a simple high, medium or low flag would be very useful. This could be done as bandwidth priority and/or a sequence priority for chunks - H M H M H L for example and/ or a latency delay - H could be immediate, M every 10 min and L every 1 hour - I leave it up to you guys.

 

5. Conflict resolution UI in case of a file having been modified on both devices separately since last sync.

 

6. IMPORTANT - For the Android App -

 

a) A help file for android app - what are send and backup tabs for?

B) A method of highlighting activites taking place in the app as well as bandwidth utilisation (cumulative and instant)

c) Prioritisation and conflict resolution as given above.

 

Keep up the nice work, Guys!

 

TIA

Edited by GreatMarko
Struck-through items are suggestions which now have their own dedicated threads in the Feature Requests forum. Greyed out items have since been implemented
Link to comment
Share on other sites

Sync over specific network interfaces

 

Note: this is a re-post of an earlier thread. It was suggested by one of the admins that I add it to this thread.

 

Some of the files I'm planning to sync from my MacBook Pro to my Windows Home Server are very large (virtual machines) and as such I'd like to enable syncing only when I've connected to my local network using Ethernet (rather than using the WiFi). This is because a sync over anything other than a local ethernet connection will take forever, massacre my WiFi and max out my broadband monthly data cap in no time.

 

Request:

  • For each sync folder, allow the user to specify which network interfaces may be used for syncing (default = All), so as I can de-select WiFi for these folders. On my mac, for example, I have the option of two thunderbolt ethernet interfaces, the WiFi and bluetooth. I'd like to enable the two ethernet interfaces for my VM sync folder and disable the others.
  • For each sync folder, allow the user to specify if it should sync over LAN only (default = False) so as I can prevent these folders from syncing over the internet (when I'm in the office, for example, or maybe working on a mobile tether)

Cheers,

 

Pete

Link to comment
Share on other sites

Hi guys,

 

I would like to address some more access security. My "wish" would be that, despite the fact that the secret is hard to guess, you add some kind of password feature. Please let me explain why. The reason is pretty simple: Human nature. It is relatively easy to obtain a key when you have a quick access to a PC or human communication. Since the key is somehow visual, it would be good if you have got some non-visual item attached which is a password you keep in your memory and not written anywhere. This is the same like with credit card numbers when they introduced the 3-digit security code for online purchase. I would like to change your current secret concept to the following:

 

1. Master key = key + additional password

2. Read only key = key + additional password

3. Broadcast key = read only key as it is right now

4. One time key = key as it is right now

 

The password could simply be a kind of split secret so you cut some part of the secret and use it like the current secret and the rest as password:

 

e.g.: 30 digit key = 20 digit secret + 10 digit password

 

 

Link to comment
Share on other sites

Currently, btsync only transfers two files at the same time from the same folder if the files are <12MB in size. Also, btsync seems to only transfer a single chunk at the time which feels like a very conservative setting.

 

I'd like to propose that these were configurable, e.g. there would be a settings page where you can configure how many chunks can be on the fly at the same time and/or how many files/threads btsync can transfer/utilise at the same time.

 

This would alleviate many low-transfer-speed problems with high-latency links because it partially sidesteps the transfer window size problem. Also some of the ISP throttling could be avoided this way.

Link to comment
Share on other sites

capability to 'view' a folder or rather mount a 'view' to the swarm using the read-only key.  Use case is specifically to distribute videos and images across various computers but be able to watch or view the files via streaming.  Could use this with Plex and mount up a read-only btsync folder as a library and watch from the swarm :)

 

Secondly, +++++++++10000000 for shadow copy sync on locked files.  The method I would prefer is to shadow copy the locked file and sync, then when the lock is released switch back to direct sync of that file.  I believe that you can pull the diff between the shadow copy and 'live' without having to hash the whole file through a .net library.

Link to comment
Share on other sites

My request is for more control over connected devices.

 

Initially a list of previously connected devices to a given share to remain after disconnection. Currently the list will clear after a while.

In addition to the list remaining, I would like a kill switch for the devices in the share list (e.g. a phone or laptop is lost or stolen, the links can be severed).

 

This would appear to be a case for a master version of the program, or password locked tab to give administrative powers so that a compromised machine cannot be used to back feed the kill...

 

This may also be possible if each share could have multiple ReadWrite and ReadOnly codes, individual code removals would kill the remote device.

 

Of less importance, but in the same vein, information of the sync progress status on each device as well as the last connection would be useful - knowing when I turn off my office PC that my laptop at home has caught up would be nice!

 

Thank you for all your efforts so far - its looking good.

Link to comment
Share on other sites

First of all thank you for this GREAT app!!

 

I use BTSync mainly as a backup solution with Windows and Android clients which are backuped to my NAS (NAS4FREE) but also to sync folders between two NAS4FREE (FreeBSD based) servers. Since this is a wishlist I would really appreciate to see the following features implemented in BTS:

  • https access for the builtin webserver!!!   ++1
  • advanced settings implemented in the webGUI (like in the windows client) because the use of a config file (can) interferes sometimes with the options which are configurable via the webGUI -> webGUI overrides the config-file settings ...
  • hierarchical severity levels for the log file (like INFO, WARNING, ERROR, DEBUG, ...)
  • consistent (=the same) information in logs for all kind of clients (Windows, FreeBSD, ...)
  • if a sync folder will be removed from syncing at the client/webGUI the hidden files created by BTS should be removed as well by BTS
 
Thanks in advance!
Link to comment
Share on other sites

It'd be nice to have a bug and/or feature request database so that us users know our suggestions are not disappearing into the aether.

 

Don't worry, suggestions & feature requests made in this thread don't just disappear - they're not ignored!

 

The developers are paying attention to what's posted in this thread, and are keeping track on how popular each suggestion made here is.

 

In time there may well be a dedicated "Feature Requests" sub forum or similar, however, at present, do bear that Sync is still in "beta". During this development phase, the developers feel the best way to collect user suggestions and feature requests is via this thread.

 

(There's also a separate mobile app Wishlist thread here, and an API Wishlist thread here)

Link to comment
Share on other sites

Guest proactiveservices

Don't worry, suggestions & feature requests made in this thread don't just disappear - they're not ignored!

 

Thanks for the reply! Nice to know things aren't getting lost :-)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.