peterk

Members
  • Content Count

    12
  • Joined

  • Last visited

About peterk

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  1. > I have not tested this, but BTSync is supposed to handle removable drives now. In earlier versions > it would indeed interpret an unavailable folder as "all files have been deleted" and merrily sync that > deletion to the other nodes. Whoa! sounds horrid in that means if there was a drive going off line or having an IO error due to any number of potential failures it might have deleted everything everywhere. Very dangerous! I would think it should have a UUID for the share in the .xxxx file on the shared folder an no action would be taken unless it was able to access the folder *and* verify the identity and integrity of the control info etc.
  2. I have a partner who wants to keep backups of a folder on his NAS server. But It can't have BtSync installed on it as it operates wholly from unmodifiable firmware. That said if he installs BtSync on a machine on his network it would work but in this case the "drive" will go off line and be un-mounted whenever he takes his machine off his LAN or the LAN goes down. Will this work? One wants BtSync to simply suspend whenever the network drive is unmounted, and then resume whenever it is re-mounted and resume syncing from the other machines when it is re-mounted all in the background without having to manually stop it before leaving the space ( and maybe going on a wifi in a cafe) and then resuming sync to that folder after the network drive is re-mounted. One surely wouldn't want it to somehow sense the contents were "deleted" and propagate a delete to any other listening clients or other errors to occur. Also is there some safety if another drive is mounted to his machine on another network (ie: /backup where it is mounted with the same path as the one BtSync is registered as sharing? Does it install a ".BtSyncUUID" or whatever at the root of the shared directory to make sure it doesn't accidentally start synching to the wrong mount? Thanks.
  3. Yes - two things, encrypted remote storage for untrusted ( or partially trusted ) rental storage on third party servers with "write only access" from your private machines This seems like a non-trivial problem on how to prevent manipulations on 3rd party machines from messing with yours such that any changes on the 3rd party wioll not propagate and will be refreshed from one of your fully trusted machines upon next contact. This sort of hints at a way to enable small scale places like notary public businesses and other bonded services like accounting firms, estante lawyers, etc etc to offer such services for their clients.
  4. I some ways yes. I believe I understand the de-centralized nature of peer-to-peer which is why I like it but not the specific intracacies of the torrent protocol - I *want* the peer to peer architecture, that is assigning direct connections between peers for bandwidth optimization and distributed reliability. I would prefer if we all had publicly accessable addresses and peer trackers were not necessary but this ( alas ) is how the internet has evolved. - I desire not to be *required* to be dependent on the existence of peers/trackers outside of peers configured for my "peer group" that is the ability to use one ( or more ) of "our" peers as "private" trackers. Hopefully if any peer in the graph can be reached, it can inform the contacting peer of the existence and reachability of any of the other peers it has contact with. If that is true then if any peer has a public IP address then it can effectively *reliably* allow all the other NATed peers to reach each other if part of the distributed reachability graph database is lost. The more peers that have pieces of the reachability graph the better. - enabling a *reliable* always contactable tracker either within a private firewalled off LAN or on a network segment that for some reason ( natural disaster, ISP port blocking, etc etc ) might be disconnected from the greater cloud. Or enabling a private tracker cloud that uses other ports that are not part of the "torrent cloud" for one reason or another such as preventing malicious DDOS attacks on the trackers. - In no way ( unless the ouside tracker cloud contact is disabled ) preventing peers from using the greater torrent tracker cloud.
  5. Is there a way to activate an email gateway for forum topics ? for either digest or per message ?
  6. Yes adding a "move" command into theprotocol similar to "git mv" would be great so as not to have to retransmit already resident data,
  7. 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. Thanks.
  8. What is the format of .SyncIgnore ? 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" for each one. ie: does "folder/**" mean recursive 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 overwrite (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 ) for a secret later. Whatever the format of course, it needs to be fully documented in the user guide. Thanks.
  9. If I have one instance of Sync running on a machine with a publicly routable IP address or domain name, and, I have entered this machine into the "use predefined hosts" entry on the other peers, will this machine operate as a "rendevous" server and allow the other peers to connect directly between themselves without relaying content through the publc server. Even if all other public rendevous mechanisms ( ie: tracker server, relay server, and external BHT network ) are disabled ? If not this would be very desirable to have. PK
  10. I just installed BTSync on some mac OSX devices. My mom bought a new macbook. The macbook was initialized using the apple "migrate tool", It simply copies all the apps and *THE DATA* from the source machine to the new machine. --> This resulted in copying the BTSync cache and config files from the origin iMac. This caused both copies of BTSync to use the same port number and config file which caused one machine to mask the other and other on the local network, and other funkyness. I sussed it out and after deleting the configuration and cache files ( hard to find and the cache and config file locations not documented ). After doing so and re-running the BTSync app on one of the machines proper function was restored. It would be appropriate to store a "unique machine ID" or whatever in the config files so that if it is run on a newly "migrated" machine or otherwise copied, machine specific information will be re-initialized. If not, a lot of people who don't know how to debug it are going to have similar problems. PK
  11. Yes - In general, all features so a peer-to-peer system can replace "TimeMachine", "iCloud" and "DropBox" on my families pile of devices. ( I am effectively their "tribal" administrator ) One of these is time based scheduling to avoid backup latency and resource consumption conflicts. Potentially scheduling of "bandwidth restrictions" for different times of the day.