xtraeme

New Members
  • Posts

    10
  • Joined

  • Last visited

Recent Profile Visitors

465 profile views
  • Moe

xtraeme's Achievements

Member

Member (2/3)

  1. About 2 years ago I setup a sync point between a Surface and my Desktop machine. Both machines had ownership privileges. The Desktop box still has ownership, but this morning the Surface displayed the message "an owner removed your permission to access $name_of_share$". Looking through the sync.log I see: { "id": "<async message id>", "response": { "folders": [ { "access": 4, "archive": "C:\\_Share\\.sync\\Archive", "archive_files": 0, "archive_size": 0, "available_space": "25.7 GB", "date_added": 1572453485, "down_eta": 0, "down_speed": 0, "down_status": 100, "error": 111, "errors": [ { "data": { "error": 111, "error_scope": 2 }, "id": 0, "last_updated": 1578643879, "size": 1, "type": 1 } ], "files": 8534, "firstsynccompleted": 1578504639, "folderid": "12345678901234567890", "has_key": true, "id": "12345678901234567890", "indexing": false, "is_owner": true, "ismanaged": true, "iswritable": true, "last_modified": 1578504683, "local_files": 8534, "local_size": 34522859659, "locked_files": 0, "name": "_Share", "onlinepeerscount": 0, "path": "C:\\_Share", "paused": false, "peers": [ { "direct": true, "downdiff": 0, "downfiles": 0, "has_files": 1510, "has_files_size": 1488353247, "id": "ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMN", "isonline": false, "lastreceivedtime": 0, "lastseentime": 1578601676, "lastsenttime": 0, "lastsynctime": 1578504639, "name": "SERA", "updiff": 0, "upfiles": 0, "userid": "ZEBRAZEBRAZEBRAZEBRAZEBRAZEBRAZEBRAZEBRAZEBRAZEBRAZE" } ], "remoteindexing": false, "size": 34522859659, "status": 7, "stopped": false, "synclevel": 2, "totallastsynccompleted": 1578504639, "up_eta": 0, "up_speed": 0, "up_status": 100, "users": [ { "access": 4, "id": "DONKEYDONKEYDONKEYDONKEYDONKEYDONKEYDONKEYDONKEYDONK", "name": "S5" }, { "access": 4, "id": "ZEBRAZEBRAZEBRAZEBRAZEBRAZEBRAZEBRAZEBRAZEBRAZEBRAZE", "name": "S10" } ], "warnings": [] }, { "access": 4, "archive": "C:\\df\\E\\_share\\.sync\\Archive", "archive_files": 0, "archive_size": 0, "available_space": "25.7 GB", "date_added": 1575896413, "down_eta": 0, "down_speed": 0, "down_status": 100, "error": 0, "errors": [], "files": 73569, "firstsynccompleted": 0, "folderid": "52442552442552442552", "has_key": true, "id": "52442552442552442552", "indexing": false, "is_owner": true, "ismanaged": true, "iswritable": true, "last_modified": 1576000532, "local_files": 73567, "local_size": 2670455283, "locked_files": 0, "name": "_share", "onlinepeerscount": 0, "path": "C:\\df\\E\\_share", "paused": false, "peers": [], "remoteindexing": true, "size": 2676771592, "status": 8, "stopped": false, "synclevel": 2, "totallastsynccompleted": 0, "up_eta": 0, "up_speed": 0, "up_status": 100, "users": [ { "access": 4, "id": "DONKEYDONKEYDONKEYDONKEYDONKEYDONKEYDONKEYDONKEYDONK", "name": "S5" }, { "access": 3, "id": "CELERYCELERYCELERYCELERYCELERYCELERYCELERYCELERYCELE", "name": "S" } ], "warnings": [ { "id": 0, "ignored": 0, "last_updated": 1578504548, "size": 2, "type": 2, "warning_type": 7 } ] } ], "status": 200 } } I chopped this up a bit a to hide any actual ids and to remove other shares, but if requested I can provide more. There was only one entry with "warnings" so I made sure to include that as well, but it was for a different sync point. Restarting Resilio on the Surface seems to temporarily have fixed the problem, but I'm concerned about potentially losing files or losing access when out. Another consideration is that the Surface hit a low disk space situation (24GBs or so) that may have somehow caused this. Whatever the bug is, it is concerning.
  2. I have about 30 or so different shares with about 1/3rd of the shared folders being related to my personal network of machines, another 1/3rd related to an open source project, and the final 1/3rd related to a collaboration with a few professional colleagues. It would be really nice if I could associate the 1st group of shares together as: 1. Personal / Home The second as: 2. Open Source Project and the final as: 3. Collaboration This would declutter the interface by hiding the groups I am not interested in. Are there any plans for this sort of thing?
  3. Thanks Marko. You might want to flag management as well.
  4. I recently did a contract with a Fortune 500 client that requires SAS 70 Type II, SSAE 16, ISAE 3402, and/or SOC2/3 certifications amongst other guarantees like 99.9% SLAs and so on and so forth when working with external vendors. Moving data securely is always a sensitive issue. The company required AES256 at rest and during data transmission. BT Sync (now Resilio) only currently supports AES-128, which is problem number one, but I still floated BT Sync for transmitting large assets that weren't mission critical. During a security review legal called attention to a clause in Resilio's Terms of Use. The proposal to use BT Sync was ultimately shot down because the wording in Resilio's Terms of Use suggested there might be a backdoor in the BitTorrent Sync / Resilio software that allows Resilio and/or its partners to access user assets through an undisclosed channel. The exact complaint was with the wording in the "Terms" as seen when installing or upgrading to Resilio for the first time: https://getsync.com/legal/terms-of-use/ The specific complaint was with section 7.a and 7.b (Investigations). I pointed out that "Materials" was defined as: The problem is that "Your Content" and "User Content," defined in section 2.b, are still open to interpretation in the ToS since "Service" is broadly defined (in section 1.a) as: Section 2.b (Use of Services & Materials) then states: This was the deal breaker because "Service" includes the software used to transfer data (aka BitTorrent Sync or now Resilio), not just the web site(s) and emails. Moreover, the Privacy Policy didn't categorically state that Resilio is incapable of tracking and accessing user files merely that Resilio doesn't -- which could be a matter of choice. I would like to recommend BitTorrent Sync again in the future, but I know many of the clients I work with will go through the same process and ultimately voice the same concerns. Are there any plans to provide clearer language that categorically states Resilio / BitTorrent Sync has no known backdoors that would allow the company or any outside parties from snooping on clients data and no known mechanisms to subvert the security of the software?
  5. I have a VVEngine schedule that does syncs every hour on the hour. If there is no conflict, VV silently copies the files over to the other machines easy peasey. When a merge conflict crops up VVEngine sends out an alert saying that a manual merge needs to happen. There is no reason for BT Sync to auto-attempt a merge. That would be awful. All it needs to do is keep a shallow history to show that the two files are no longer operating from the same base. Computer 1 / Computer 2: Hash 0: File A (rev. 0) Computer 1: Hash 1: File A + mid file edit (rev. 1) Computer 2: Hash 2: File A + data append (rev. 1) BT Sync tries to merge: Hash 1 != Hash 0 Hash 2 != Hash 0 Hash 1 != Hash 2 (obvious merge conflict, notify user to resolve the problem, rather than using whichever is newest -- which is what BT Sync currently does -- dangerously overwriting data). At this point if BT Sync were doing things properly it would do one of two things: 1. Send out an alert that a manual merge needs to occur 2. Run a user-defined script to resolve the conflict. If the user defined script fails (return code 0: success, 1: failure), send out the alert in #1. I am not sure if you have done software development work before, but if you have you probably know developers like to submit their code to Perforce (or to whatever SCM system they use) as early as possible because whoever checks in code afterwards has to resolve any merge conflicts that exist. The general rule of thumb is to submit code often because resolving complicated merges can become a nightmare down the road. Sometimes this is unavoidable. When significant code changes need to happen, it is a good practice to create a branch so updates from the mainline can be regularly merged in to the experimental branch to keep the two branches from diverging too much. Not really. If the files were binary, sure, but they are not. The scrapbook example is a somewhat simple case. Since the scrapbook.rdf is RDF/XML. All that has to happen to automate the merge is to create an XSLT transform to sort the data by the id value (a date/timestamp). Next do a command-line diff. If an item has been deleted/added/edited on one side and hasn't been touched on the other. The script would insert or remove the data on the opposite side. If the data inside the element is different between both sides a manual merge needs to happen. This is just par for the course. Manual two way merges are a normal part of day-to-day life when doing development work. This assumes merges have to happen at the file level rather than at the content level. Imagine if two people are trying to work on an ASCII text document together. They could choose to use something like TitanPad (which isn't private) or create a text file and try to synchronize it between their machines. Setting up a full SCM like SVN for a simple text file is overkill. A simple shallow merge tool is all that is needed and that is exactly what Vice Versa and BT Sync are expected to be able to handle. If BT Sync only handled differences at the file level that would mean the two people working on the text file would have to break up each paragraph as separate files. That is completely unworkable in any sort of real world scenario.
  6. I am paying customer of both ViceVersa and BitTorrent Sync. I use rsync, robocopy, and numerous diff tools with various levels of automation on a daily basis. Frankly, considering BitTorrent Sync has no way to do conflict resolution between files. It is basically just a toy for people who need mirroring. ViceVersa and VVEngine solves this much more gracefully. For example, here is a simple test case. 1. Install Gomita's Scrapbook in Firefox (https://addons.mozilla.org/en-US/firefox/addon/scrapbook/) 2. Save a web-link at any site using Scrapbook (instructions) and synchronize it between two machines 3. Once both machines are in the same state, save another link on machine #1 4. On machine #2 save another link to something else 5. Quit out of Firefox on both machines and wait for BitTorrent Sync to sychronize. 6. Load into Firefox on both machines and notice the most recent save overwrote the results from the older save. No conflict files exist in the .sync folder or elsewhere to show the scrapbook.rdf was different between the two machines. This is unacceptable in a collaborative environment. To make an analogy, as of right now BitTorrent Sync is a bit like a car without doors, seat-belts, or any other protective measures, because it just allows data to be overwritten purely based on timestamp and then even worse -- doesn't even say that it did so. While I love the philosophy behind BT Sync, until this is addressed I'd be better off just using Beyond Compare and a manual diff and merge.
  7. Why is everyone comparing BT Sync with DropBox when they should be comparing it with ViceVersa Pro? Also notice that ViceVersa is a one time cost outside of updates.
  8. A week or so ago I upgraded to Pro to experiment with the new 2.0 features. I have two machines that I am syncing. One is a desktop with literally millions of files from a rather large development project extending Chromium. The other machine is a Surface and only imports subsections of the project over two directories. So imagine my surprise when I upgraded from 1.4.111 on the Surface and all 17 shares were imported on to the Surface from my main desktop after I linked the two devices. The Surface was setup to fully sync; so it started to download the whole project. The BT Sync client immediately locked up. In a panic, since my disk space was quickly filling up, I quickly killed the internet connection. After several crashes and wasting time sitting through the ten minute long load screen I was able to start to disconnect the shares that I didn't need on the Surface. This is incredibly bad behavior. Please in the future ask users what shares they want to import or at the very least start them in a disconnected state. Don't just assume all shares are wanted uniformly across all devices. Even worse I just discovered that apparently deleting a share on one machine will now delete it on the other device. This is just getting ridiculous. I never had half the number of problems with ViceVersa Pro.
  9. I'd just like to pop in and reiterate Bob's point. I was a huge fan of BT Sync originally because it was easy to manage and sync numerous folders with family members machines, but now that I'd have to buy a perpetual license for each family member. The entire thing falls apart. I'm willing to pay a reasonable amount upfront to purchase a license for a specific version of the software to be reused in several locations. However, as it stands if I can only share 10 folders with people who don't have a license. Then BT Sync 2.0 is useless to me. So for now I'll continue to use the 1.4 version of the software and hope a better pricing model materializes. Edit to add: A thought just occurred to me that maybe a solution is to have two versions of the Bittorrent Sync client? The pay version of the client would have the full ability to do read-write sharing and update material. The free version of the client would have read-only access with 10 writeable user-specified folders and only be able to mirror data for the rest. That might be a good trade-off.
  10. First, I want to say BitTorrent Sync is a brilliant concept. A couple of years ago I was considering working on a distributed versioning filesystem using bep_0003 as the basis for how files were synchronized. So it's nice to see Bram is thinking along similar lines. Anyhow, getting to the feature request, since files and directories are sorted using the native operating system's lister. I think BT Sync would be a lot easier and more useful to the end user if the client was more consistent in how it presents and sorts files on mobile devices. Why is this important? It is ridiculously tedious on the iPad scrolling through tens of thousands files to get to the bottom of the folder, just so I can finally click on the directory that I ultimately wanted to navigate to. Any photographer who takes lots of pictures knows exactly the sort of problem that I'm talking about. It would simply just be nice if BT Sync was consistent and showed files in the file list the same way across all devices. The Mess That Is File Listing and Sorting To give a sense of how much of a jungle it is out there. Lets go through a couple examples to see how various operating systems pass folder-file lists to BitTorrent Sync. Method #1 - iOS BT Sync sorts files on the iOS first by: {directory-file insensitive} {numbers, A-Z first (case sensitive)} {punctuation, a-z last} Note: when I say punctuation I mean things like: [_-,.] The iPad iOS lister, like OSX, doesn't distinguish between files and directories (I'll refer to this as directory-file insensitive) and intermixes the two as though they are the same thing. Method #2 - OS X On OS X, the files shown in Finder are sorted a bit differently: {directory-file insensitive} {punctuation first} {numbers, a-z last (case insensitive)} This is a curious departure from iOS when you consider that under the hood iOS basically uses the character code (e.g. 0x31 = 1, 0x41 = A, 0x61 = a) to figure out the sort order. This means the developers, as a conscious part of the design, had to intentionally set character codes 0x5B to 0x60 to sort before 0x31. I suspect this was to make OS X more like Windows. Method #3 - Windows In a Windows environment files are sorted by: {directories first} {files last} {punctuation first} {numbers, a-z last (case insensitive)} Method #4 - *NIX Most *NIX environments list directories and files in a manner similar to iOS (for obvious reasons), but there are also differences due to how the locale is configured. In Gentoo, for example, the default unaliased 'ls' with LC_COLLATE=en_US.utf8 will show: {directory-file insensitive} {punctuation [_-,.] is ignored because of LC_COLLATE, the first [a-zA-Z0-9] character is used} {numbers, a-z first (case insensitive)} By setting and running: LC_COLLATE=C ls This gives results that are more or less identical to what we would get on the iPad or other iOS devices (method #1). Of course we have more room for hacks on open operating systems (jailbroken / rooted android devices excluded since they are easily invalidated) because we can alias 'ls' and export LC_COLLATE to be what we want it to be. Ideally I prefer getting as close to the Windows approach (method #3) as possible: LC_COLLATE=C ls -a --group-directories-first Though unfortunately the 'C' codepage isn't case insensitive like en_US.utf8 and sorts using a variation on the method #1 approach that is directory-file sensitive (method #5). {directories first} {files last} {numbers, A-Z first (case sensitive)} {punctuation, a-z last} Method #6 - Android On Android 4.4 KitKat the sort function uses: {directories first} {files last} {numbers, a-z first (case insensitive)} {punctuation last} And to think - there are even more permutations possible! Ridiculous, huh? How Do We Make This Easier? In an ideal world users should be able to specify how they want to sort (name: A-Z ascending vs Z-A descending, etc.) and display (using the methods outlined above) their files. Full customizability is a bit of work, of course. So for the time being an option to allow advanced users on *NIX-style OSes (iOS, Android) to go into the settings to specify the code page through LC_COLLATE and manually pass parameters to the API that retrieves the files list would be a nice workaround. Bottom line though it shouldn't be so tedious to navigate through folders. Either a directory tree-view or search function is needed, file sorting by name / date / extension should be added, or something needs to be added to make navigation more efficient.