iMok

Members
 View Profile  See their activity

  • Posts

    14

  • Joined

  • Last visited

  • Days Won

    2

 Content Type 

Posts posted by iMok

  2. If You Have Sync Issue

    in Sync Troubleshooting

    Posted

    Issues I've encounterd so far:

    Does not prevent computer from sleeping during a large upload (OS X)

    I prefer to keep it like now, going to sleep. It scares me the fact of being on battery and being unable to sleep, leading to battery dry. If your priority is syncing, you have a whole arsenal of tools to keep your computer awake. These are the kind of things that should never be hardcoded in BT Sync

    Does not use OS X Finder Trash - keep using .syncTrash

    This one I think was already asked for and would be optional in a future release

  3. Wishlist (Archive)

    in Feature Requests

    Posted

    We should take in account in this WishList that almost everything is doable, but many of your request are far behind of this software "explicit" purpose or should be done with a different approach, not at the SyncApp end

    The beta version will need a detection of the network I'm connected to such that I get asked weather I want to sync or not.

    Why?

    I use syncapp on my laptiop at home, then I went to the campus and forgot that syncapp is running. After 10 minuted I got an email from the IT department because they detected p2p network (they said someting about ToS and possibliy illegal downloads, just the typical bla bla).

    When this app is set public, regular users might get ->really<- scared when they get such an email! And this is no good.

    How:

    When installing ons should get asked: a) always sync B) whitelist sync

    The details are up to you=)

    Network profiles have done for ages what you ask for. Profile to launch SyncApp when connected to a "safe" network, kill it when not.

  5. Feature Request: Disable Disk Polling

    in Sync General Discussion

    Posted

    Hello,

    Thank to all devs the progress made on SyncApp.

    After some weeks playing with SyncApp, I found some roles where the SyncApp share could avoid most of disk i/o thus allowing disk to stay in standby mode, improving power savings a lot. This ideally would be a per share setting, or a global setting that could be overridden per share

    Comes to my mind a NAS instance of SyncApp that performs as a central mirror that runs 24h. No changes are made locally so we could avoid all i/o related to filechange checking, we'll have an option to manually trigger a filecheck when needed. This will let the disk enter in standby mode most of the time.

    A SyncApp share not being actively modified on the current machine could be set to this setting thus letting longer disk standby periods, improving battery life in a notebook.

    Allowing the user to set the "Check for filechanges every X s":

    - 0 to disable

    - Default

    - Long periods (3600s)

    What do you think?

  7. Wishlist (Archive)

    in Feature Requests

    Posted

    Whilst a "cloud storage" service may be nice, I think many users simply wouldn't use this, either becuase they already use a different cloud storage solution (i.e SkyDrive), or they wouldn't trust BitTorrent with their data.

    What's really interesting is if you take the example of Cubby (cubby.com). They initially offered a free "direct sync" feature in their sync software allowing you to sync peer-to-peer, along with a few GB's of free cloud storage so that you could sync between devices when they were off-line.

    However, Cubby then made the crazy decision to start charging for peer-to-peer sync, but tried to "sweeten" the deal by including 100GB of cloud storage as part of the new price. There was a massive backlash from Cubby users (http://help.cubby.co...o-basic-version) over this change, with many arguing that they simply didn't need 100GB of cloud storage, and shouldn't have to pay for that when all they want to be able to do is sync files between their own devices! ...the result being, users left Cubby in their droves!!

    So, the lessons for BitTorrent to learn from this Cubby fiasco, are; "Are users really looking a new cloud storage solution, a peer-peer sync solution, or both?" ...Whilst it would of course be perfect to have both of these features in a single offering (like Mesh did!), BitTorrent need to be careful that the peer-peer sync side of things wouldn't suffer as a result of any venutre into cloud storage! (in a similar way that the Cubby service has suffered)

    Given that there are many FREE cloud storage storage offerings currently available (SkyDrive, DropBox, GDrive, etc), I think BitTorrent could have a hard time competing with these in offering their own cloud storage. SyncApp currently fills a nice hole in the market, and I for one hope they take full advantage of that by developing an amazing peer-to-peer sync solution, and then worry about any potential cloud integration at a later date!

    Agree, SyncApp needs to be polished and offer a paid cloud storage option for who need it. Even a minimum free 1GB storage cloud cache to sync document changes without both ends being up would bump user base a lot.

    Anyway, I expect the base system to be kept as it is

  9. Symlink/folder Junction Support?

    in Feature Requests

    Posted

    I'd like to be able to symlink content into a shared folder. There are times when I'd like to consolidate items from the various sources into one destination on my backup/secondary. For example I don't want to sync all of my iTunes Media but I'd like to pick and choose items that aren't available from the cloud into a common shared folder.

    Perhaps it's safe to share each of those folders but the overhead of setting them up is greater... alternatively it may be easier to share a common ancestor folder but that may include gigabytes of files that I don't care to backup.

    Symlinking as you want is doable with your OS tools at a directory level. If you don't like command line, for windows there is https://code.google.com/p/symlinker/ and for Mac http://www.macupdate...41493/symlinker

    You should place the symlinks before adding the share to a given SyncApp instance