rstarkov

Members
  • Posts

    49
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by rstarkov

  1. I much preferred the old way of sharing a folder. It was so refreshingly obvious that no third parties needed to be involved. Not anymore.

     

    It's no longer even possible to just add a folder by simply pasting a key. I *HAVE* to use a link in 1.4. Exchanging one-time keys was one of the best parts of it, and now you've gone and ripped it out completely.

     

    It's especially annoying that by default, my one-time secrets end up being sent to your servers. The very same one-time secrets that would enable you to access my files. Now, I already have to trust you not to be evil, but this is altogether different, because the software itself does not need to be evil anymore; only the people on the other end of link.getsync.com.

  2. 1. These animations do rather suck over Remote Desktop. An option to turn them off would help using this new UI over RDP.

     

    2. No more keyboard navigation. Not even Esc to cancel a dialog, let alone such niceties as using the arrow keys to select a button, or (god forbid!) an Alt+Letter shortcut! To be fair, the old UI was also shortcut-free, but at least it didn't mess up the things one gets for free when using a proper UI framework. So not happy to pay this price for the eye candy.

     

    3. Would it clutter the UI too much if the "History" button was labelled? I bet that if you run a usability test, you will find that everybody has to hover it to find out what it does:

     

    AyC021B.png

     

    This icon is in no way a standard icon for "history", and there's plenty of space available to label it. My phone uses this icon to mean "alarms", pretty much guaranteeing that if you add more mysterious icons, the only way I'd be able to pick out "history" will be by hovering each of the non-standard icons every time.

  3. Use case: deliver large backup images from servers (created there on a schedule) to several remote locations. To secure against deletions, we rely on the Archive folder, although it might be handy if BTSync could just have an option not to propagate deletions. Each remote location also runs a script which does a periodic clean-up of older backups, so syncing deletions is not necessary in this scenario.

     

    Another workaround that is necessary here is NSSM, because BTSync can't run as a service and these are all Windows servers.

     

    Separately from that, I use BTSync at home to sync movies between by desktop and laptop, and to sync a huge number of personal photos and videos among my family members. It became great for this use case with the introduction of read-only syncs.

  4. Your first suggestion already has it's own dedicated thread in this forum.

     

    Hey GreatMarko, you've linked to this very thread here. Not sure if that's intentional, but I sure was confused :)

     

    +1 for having two kinds of SyncIgnore files; those that are device-specific and those that apply to the entire share on all devices.

    +1 for making these SyncIgnore files editable through the primary interface.

  5. Over time, many of my syncs accumulated files that are just stuck. The best BTSync can tell me about them is by saying "uploading" when I click the (i) icon. It really needs to tell me something that I can actually act on, e.g. "the file is in use on the remote device and cannot be updated" or something like that.

     

    If the remote computer doesn't even have this folder in the sync anymore, it needs to be removed from this list! If the remote computer is offline or unreachable, it needs to be clearly indicated as the reason for why the sync is stuck.

     

    4IHZBEU.png

     

     

  6. Pity. The old, native interface was great.

     

    One advantage of a web interface is that it's easier than before to make the program run as a service on Windows. Willing to sacrifice the native UI for that... although I suspect the primary motivation was that it's just a lot less work to develop a single web interface for a multi-platform app.

  7. +1. Even better if I can pause entire folders inside a sync. Then I can leave it permanently paused to exclude a folder from sync.

     

    IMO, every "pause" feature needs to be available with a timer. It's so annoying to need just a 30 minute pause but forget to resume it and find this out days later. It would be great if there was a "Pause for 1 hour" along with "Pause".

  8. BTSync is great, but this is the biggest missing feature, severely limiting deployment on servers and multi-user laptops. Hacks and work-arounds suck. Reading back, it appears the developers are unaware why services are important. Explanation: it's because regular programs don't run until someone logs in, and on a server, nobody logs in immediately following a reboot.

     

    I've already decided against using BTSync on a server based solely on poor experience with running non-service-compatible programs as services in the past. Now I'm running into a major issue getting stuff synced on a laptop that I share with my wife using separate user accounts. It should sync regardless of whether the person who set up the sync is logged in!

  9. 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.

  10. I would like to sync my application-specific data using BTSync. This data could be as simple as basic application settings, or something more complicated (e.g. a photo library with metadata).

    Ideally my application would tell BTSync it supports syncing of <insert text description> (e.g. "FooLibrary photos for Bob" or "AcmeWidget settings"). The user would then go to BTSync and "Add Application" just like they would normally add a Shared Folder. This would show a list of applications which report some sync ability. It would then act just like a Shared Folder acts currently, including keys and such.

    On the API side, I'd like my application to be queried just like a filesystem would: what "folders" are there in the root folder, and what "files" (binary blobs) does each "folder" have. Perhaps BTSync could also ask the application for the file hashes, just in case it has them (but if not, could compute them by itself).

    In case you're wondering why I might want my photo library application to offer sync instead of just syncing the photo files. Well, suppose I have carefully tagged each photo as "show this to Jane" or "show this to Bob". There is no *folder* that contains all the photos to be shown to Jane. Likewise for Bob. Moreover, the folder structure is sensible in another sense; it organizes the photos by event. So Jane might get "C:\Photos\Event A" and *some of* "C:\Photos\Event B", while Bob would get *all of* "C:\Photos\Event B". BTSync wouldn't need to know any of these details; it would just query my application for a list of folders and files, and the application would figure out what to say.

    My application would, of course, have to report that it supports two separate syncs, a "Photos for Bob" and a "Photos for Jane".

    These are some grand plans I've outlined, but it would also be unbelievably awesome if this were actually possible. So many use cases and possibilities are currently prevented by the inherent difficulty of actually implementing that sync feature for my Super Cool Photo Library Manager... Please be the ones to fix this!

  11. What would be needed is to do a one-way sync initially to make the remote device match the 'up-to-date' folder, then revert back to two-way sync. - I think this could be hard to explain from a UI / usability point of view though.

    Exactly. Here's a UI idea: when you add a secret, offer an "Advanced" button. Pressing it would offer these choices:

    (•) Merge this device with other devices

         Any files that exist only on this device, or only on other devices, will be copied to all devices

         The latest version of every file will be kept on all devices

    ( ) This device has the master copy of this folder

         Any files that don't exist on this folder will be deleted on all other devices

         Any newer files on other devices will be discarded

    ( ) This device has only out-of-date files

         Any files that only exist on this computer will be deleted

         Any newer versions of files on this computer will be discarded

    I think the biggest difficulty here is not in UI, but in deciding how exactly it should work. If you choose that this one is the master device, when does that status end? Or, in the words of johnmarshall4, when exactly does it change from one-way to two-way?

    I would also find a fourth option useful, one that doesn't sync files that only exist on this or on the other devices, or differ in version, until the user chooses how to resolve the conflict. But the above three would already be a huge help.

    Until then, I sync folders using Beyond Compare, and only then feel confident to run BTSync on them.

  12. I would like to move where a directory is synced to without re-syncing it.

    Suppose I have given a read-only key to 10 other people, and now I want it stored in a different place on my machine. Is there any way of doing that without having them all delete the old and add a new key?

  13. Kos, this sounds fantastic but is it really completely true?

    Take μTorrent, for example. For the sake of the argument, forget about trackers (since BTSync doesn't have them). The DHT is bootstrapped using the bittorrent.com and utorrent.com domains. What, exactly, makes it impossible for you to shut down the entire DHT?

    Doesn't the same thing apply to BTSync? Couldn't you just shut down whatever URL is used for bootstrap and have the network shrink and die over time?

  14. It would be really nice to have a sync solution that allows me to specify how to perform the initial sync, for a change. I really don't understand why no sync tool ever does this.

    9 out of 10 times I have an up-to-date folder on one computer and an out-of-date folder on another. With the scheme you guys chose, I have to nuke and resync the out-of-date folder, otherwise the up-to-date folder gets polluted with deleted files. Not good.

  15. I'm syncing a folder which periodically gets replicated from another location. Whenever this happens, the SyncApp-created hidden file (.SyncID) gets deleted because the source doesn't have it.

    While I can probably live with sticking the .SyncID file into the source folder too, this isn't ideal. Does this file serve such an important purpose as to necessitate its existence? It seems that its only purpose would be to prevent SyncApp from proceeding whenever the file isn't where it's expected to be - or does it do more than this?