goli

Members
  • Posts

    126
  • Joined

  • Last visited

Posts posted by goli

  1. Hey there.

     

    Seems you're right: Co-Authoring only works with excel as per-file communication. Word requires either SkyDrive or Sharepoint.

    Maybe this is something for the Wishlist thread? I think this would be a pretty nice feature if was integrated in the yet to come enterprise version of btsync.

     

    Regards,

    Stephan.

     

    [edit]

    That's basically the Sharepoint help document concerning co-authoring.

    http://office.microsoft.com/en-us/sharepoint-server-help/document-collaboration-and-co-authoring-HA102772333.aspx?CTT=5&origin=HA101812148

    Might be helpfull to be posted to the wishlist thread, too.

  2. Hey there.

     

     

    I checked it today, and it works nicely. Just switch the Excel file into the concurrent access mode. Then the lock file isn't created and Excel doesn't hold file locks any longer. And additinally, Excel scans the source file every now and then (you can configure that, minimum is every 5 minutes) and merges changes if possible. If there are changes that cannot be merged easily, a popup will ask you what to do.

     

    And you even have tooltips indicating which other computer caused what change to the document. Pretty nice. It's not realtile like Google Docs can do, but it's usable.

     

    So: As long as you stick to Excel and Word, this feature does exactly what you want.

     

    Regards,

    Stephan.

  3. Hey there.

     

    Here is another idea. You could expose your VMs storage folder by NFS on one side and mount that NFS share to the very same host computer on the other. That should break the boundaries of file system locks. If you restrict this NFS to localhost only I gues that doesn't cost your lots of performance.

     

    Regards,

    Stephan.

  4. Hey there.

     

    What you're trying to do is not possible because btsync does not synchronize a certain file as long as there is an open file lock to this file.

    You could switch your file system to one that allows snapshots. ZFS does, Btrs does as well.

    Then you can configure btsync to synchronize those snapshots instead of the original data. Then you can trigger the "take snapshot" mechanism of the file system which renders btsync to synchronize data.

     

    Having btsync to synchronize write-opened files most likely will never be implemented.

     

    Regards,

    Stephan.

  5. Hey there.

     

    You could try this one:
    http://office.microsoft.com/en-us/excel-help/use-a-shared-workbook-to-collaborate-HP010096833.aspx

     

     

    Microsoft integrated a mechanism for concurrent access to those documents.

    This setting avoids temporary edit lock files Excel usually creates ("~$file.xlsx" if the original is "file.xlsx") and introduces kind of "current user cursor" to the content of an opened file. And it slightly changes how hard Excel holds file locks.

     

    I'm not completely sure if it really works, but that since this is the way to go to have concurrent access on SMB based file shares I would expect this to work with btsync as well.

    A first small test shows that btsync synchronizes every time I hit the "save" button.

    Tomorrow I'll access the very same file in the same btsync share on another computer in my office while excel on my home computer accesses the file, too.

     

    I'll keep you posted if it really works.

     

    Regards,

    Stephan.

  6. Hey Pere.

     

    So you plan to deploy independent standalone VMs with no central account management? Then you might run into trouble -- or not, depending on how you set the VMs up.

     

    The thing is: If you have a central account management (Active Directoy would be the usual situation in case of having a Windows environment), then the setup would be the following:

    * You start the VM and set it up using your "Administrator" account.

    * You install btsync as "Administrator", but since btsync is not a service but a "Autorun" tool, that does not mean anything.

    * The first time the students log into their personal accounts (no matter what they are named, as long as those are not the "Administrator"), btsync initializes itself with an empty configuration.

     

    It doesn't matter if all students use the very same Windows logon username. Not at all. The important thing is: The account your students sign in needs to have no btsync configuration (although the Administrator account on the same machine has, they are independent and do not influence each other). This will make btsync to create an empty environment "on first start". And this very situation is what makes your btsync processes individual.

     

    As soon as you have btsync on different computers use copied sync directories (the "%APPDATA%\BitTorrent Sync" I talked about), this might cause touble.

     

    It doesn't matter at all what your user accounts on the machine is named. They can have equal names or different ones. That doesn't matter at all. What matters is the fact that the "BitTorrent Sync" directories must be based on common content.

     

    As explained, this would be the case as soon as you have e.g. an Active Directory and distinct accounts. Before your students sign in, there is not the slightest indication of the students account on a particular VM. The account on the local computer/vm gets created the first time they sign in. And that's the fact that makes btsync start with a fresh database.

     

    But would be nice if the Bittorrent staff may answer here. That's in fact something every company deployment has to deal with: Centrally managed sync configuration based on user accounts. So maybe they can give you some other hints then pointing you to difficulties the current public version has.

     

    You also might want to search this forum. There is something related to corporate/company/business. I don't know its exact state. I just added my name to the "want to be informend and participate in discusions" form the BitTorrent guys published here some months ago. But I completely lost track about that field. I don't know if I'm still on this list, have been dropped or if the list still is inatcive due to no hard facts to be announced publicly.

     

    Kind regards,

    Stephan.

     

    [edit]

     

    Actually, that's the form I talked about. Maybe you want to add yourself there and mention your use case? It's like "central deloyment of cloned vms having preconfigured btsync settings to share data" or something.

     

    http://forum.bittorrent.com/topic/23678-interested-in-sync-enterprise-beta/

  7. Hey there.

     

    To the current state of btsync I find it pretty useles to ask for this. It's still beta and not announced to be stable in the next view days. As soon as the product is stable, I have no doubt that the bittorrent guys will do anything they can to make it the most trustworthy they can. But until now there's absolutely no way to garantee that the the final product will meet any security requirement.

     

    Btsync is completely owned and managed by the BitTorrent Inc.

     

     

    I would suggest to contact them directly, because I expect you to need something like a certificate and review. And most likely that's something the BitTorrent Inc will sell to you as soon as they can (which relies on both, having a stable product and the required manpower).

     

    Every other information, even made by bittorrent staff here, will most likely not suffice for any decission concerning legal issues.

     

    Regards,

    Stephan.

  8. Hey there.

     

     

    Ha! What, and expect them to just "memorize" a string of 30+ random characters?! :P

     

    Well, you can hand them a printed version or make them type in the secret directly into their devices. If, of course, you tell somebody "I'll tell you my private share secret in person when we meet" and he arrives without anything to store this information that has been announced as being transfered verbally, then I would think it's his own fault.

     

    So yes, I would expect that and laugh on him.

     

    The last couple of secrets I used were in fact transferred this way: We were in a starbucks, I told the digits to my collegue and he typed those into his computer. That's pretty easy, and no more complicated then what happens if you sit together at someones sofa and somebody asks "hey, what's the password of your wifi". Then the very same thing happens :).

     

    I came across a website this morning for sharing things once: https://1ty.me/

     

    Nop. That doesn't solve anything. It only moves the problem from "how to transfer the 30 digits secret securely" from "how to transfer the randomly generated URL securely". I don't think that's any way better. Ok, you can rely on the share is only used by a single recipient. But what if the single person using this share isn't your friend? It could take "several files an GB" before you notice that you're uploading your personal data directly to the NSA instead of to your friend.

     

     

    I personally would use well known secure email based on public key mechanisms. That's reliable, proofed to be strong, and after the most recent events I expect everybody to know about those and how to use them.

     

    [rant]

     

    I don't expect anybody to use signed or encrypted emails in daily business or personal conversation. It's completely up to you if you want your letters being secure or not.

    But every time somebody tells me he doesn't know how to use e.g. PGP or even doesn't know that this implementation exists since 1991, which is 22 years now, I simply stop talking to him about security.

     

    If course GnuPG as open source implementation of this is even better, that should not be the point. The simple fact is: Email encryption exists for 22 years now. That's at least as long as my daily mail contacts know how to use a computer. There's absolutely now excuse to not know about that.

     

    And this, after having ranted some lines against ignorant people (excuse me for that, but I really get angry, especially all of my non computer since friends laughed at me when I told then I would perfer using email encryption) is my best bet:

     

    [/rant]

     

    Use encrypted emails as a proofed way to transfer sensible data to transfer sensible data :D

     

    Regards,

    Stephan.

  9. Hey there.

     

    What about the "add folder" button?

     

    As far as I know, mobile devices cannot "initialize" shares but only participate. So you need to create the folder on your non-mobile node (using the "add folder" button in the Web GUI) and connect this share to the mobile node afterwards.

     

    That obviously doesn't give you a full backup of you rmobile device unless you use the root folder on your mobile. But that's not a good idea, because btsync could try synchronizing e.g. "/dev", which isn't a really good idea. So I would suggest to only add a data folder, and use different shares if you want to synchronize different data folders from your mobil.

     

    If you want to really have a full backup tool: Use something that does that on your mobile device (e.g. "nandroid" for android things) and add the nandroid target folder to btsync. Then every time you do a nandroid backup, the backup files are synchronized.

     

    Regards,

    Stephan.

  10. Hey there.

     

    As far as I know, the sync apps main data folder (not the actual payload data folders containing files to sync!) contains somesthing like the "instance identity". If there are different computers having the same "identity", they might refuse talking to each other because of thinking they talking to themselfse.

     

    I don't know if there is an API method to reset this thing like the "sysprep". I would suggest to not clone btsync. You can either install btsync after cloning the computers once per computer, or you can just clean the sync app main data folder. Both will result in making each node destinct.

     

    If you're using Windows, the folder should be located at "%APPDATA%\BitTorrent Sync".

    If you're on Linux, the folder should be either on ~/.sync, or wherever you decided to put it when launching btsync.

     

    As you can see, you usually have one folder per user. Which is nice, because btsync in its current state is designed to start when a user signs in and to stop when the user signs out. So in case you have a proper user management and each of your students has his own account with unique account names, you can completely ignore this because he will get his own "BitTorrent Sync" folder the first time he signs in.

     

    As far as I know, this particular folder contains every configuration btsync uses. This goes down to which shares are connected and which ports to use.

     

    You might either want to provide a proper "how to set up btsync" tutorial for your students or search for the API part. I don't know if the API thing is available for the public or still restricted to a closted circle of enthusiasts. But if you want to make a fresh, non-configured user account start with your desired btsync configuration (and that's certainly the way to go, no matter if you install btsync afterwards, remove the "BitTorrent Sync" folder post-deployment or have distinct user account names which all results in the same setup: fresh, un-setupped btsync), using API mechanisms would be my best bet.

     

    Regards,

    Stephan.

  11. Hey there.

     

    First thing: I totally get the idea. Really nice one.

     

    But I really doubt that the average private users upstream bandwidth fits the needs of video streaming. When I do e.g. netflix, I get ~7MBit for SuperHD videos. I guess your private HD videos are quite equal.

     

    When you're at youre holiday apartment and want its TV access your personal movie library at home, your home bandwidth must be capable of providing the video in almost real time. That's unlikely.

     

    Second thing: Alternative.

     

    But step one step back. Don't think about a tiny plug for your TV (so nothing like the Chromecast thingy) but about a full blown NAS. There are numerous in the "Supported NAS" thread.

    Most of them have DLNA available, so they can stream uploaded files from the box to your TV through LAN. That's the only way to go.

    Of course this requires your NAS box to download the entire file before your TV can start playing it. But since I suspect the average upload bandwidth the real point my sollutions solves, this would be required anyway.

     

    I personally own a Zyxel NSA 310. I will hardware-hack it a bit to get rid of the original, annoyingly loud fan. But apart from that, it's pretty awesom. Really cheep and lots of features.

     

    Third: Go to the wishlist thread!

     

    That's what it is made for. I don't know if bittorent company will follow your suggestion. But requesting anything must only be done there.

     

    Fourth: Wait for the API, do it yourself or crowd fund.

     

    As soon as the API is complete and available for everybody, things like partial sync, synchronizing packages in a certain order and "download only" might be possible.

    So as soon as the API is available, somebody else can just take this API and write a nice little Cromecast or regular Android app for that. Or even some integrated Smart TV app, since all of those TVs have a (unfortunately individual and different) public API.

     

    So the main part of my fourth idea is: An open API allows foreign contributors to create programms that access the btsync network.

     

    Regards,

    Stephan.

  12. Hey there.

     

    If sombeody tells you to install something without telling you why, then just don't do it.

     

    Do you pout yourself in danger? Maybe. Btsync itself does not, and sharing a folder doesn't, too. But what if your "friend" drops a virus into the shared folder? Do you notice? Do you come here again and ask if you should open it? Do you simply open it?

     

    It all depends on how aware you are of what your're doing. And since you don't even know what he wants you to do, just let it be.

     

    Regards,

    Stephan.

  13. Hey there.

     

    What you expect isn't possible with btsync, and I don't know if it ever will be. It's simply not the target of btsync.

    Btsync synchronizes folders. That's it.

     

    If you want to access your NAS storage remotely without the need of downloading it, that's really tricky to have it transparently available. Think about your 250GB music library on your NAS, to be played in iTunes or WinAMP (RIP, :() or whatever music player you like. You would need to create kind of a virtual file system access mechanism to btsync. There is something called the "UNC path", which is designed to address remote resources. You have to somehow hook in to that. Or really create a file system driver that is able to "mount" the btsync store into a given directory.

     

    It's not that it is not possible. It definitively is. But it's really not what btsync wants to do.

     

    If you simply want a "skip auto-sync, sync-on-click" mechansim like currently available for mobile platforms, then you should go to the wishlist thread and add it there. It's already on the againda I think, but adding it once again will push this feature request. But that definitively does not give you the experience of "seamlessly work with the NAS like it is direclty connected".

     

    The current way to go is: Get yourself a DynDNS name, set up a VPN server and connect to your NAS via SMB or NFS.

     

    Regards,

    Stephan.

  14. Hey there.

     

    I think it's related to what you expect from such a thing.

    To be honest, I really don't expect a 1GBit Intel NIC inside such a box, no matter if it's $50 or $150.

     

    I cannot provide you with a large scape experience, I just have a single NAS box -- which works awesomly well, compared to what I expected.

     

    I have a ZyXEL NSA 310. It's a really cheap one, since it's only 55€ here in germany.

    Currently I run it with a 3 years old 1.5TG 7200UP Samsung HDD. I don't have the exact specificatin at hand, but it's definitively not one of the fastest.

     

    When connecting through telnet or ssh and do  "dd if=/dev/zer of=tmpfile bs=2MB count=1024", this creates me a 2GB tmpfile with 85MB/s. I guess that's nearly the fastest the HDD itself can reach.

     

    Nearby, there is an ASrock S1155 board having an intel I5 3.2GHz. This box runs VMware ESX 5.5. The ESXs only NIC is the onboard Marvel one, so no performance wonder here, too.

     

    On this ESX I just created an Ubuntu VM and copied some data to give you some numbers.

     

    When trying scp, I'm on between 8MB/s and 14MB/s, depending on the cypher I use. The fastest is everything with arcfour with 14MB/s, Ubuntus default does 8MB/s. It's obviously limited by the NASs CPU, since the sshd is on 100% load while copying.

     

    When trying wget from the NASs FTP server, I get 60MB/s. The 2GB tmpfile goes within 32s.

    This seems to be CPU limited, too, because the "pure-ftpd" is on 100% CPU when copying.

     

    In both situations I targeted the output to /dev/null ("wget ftp://mynas/files/tmpfile -O=/dev/null") in order to not limit the NAS performance test by local HDD issues.

     

    That's not "blazing fast", but it realy is more than I expected.

     

    I don't know what NFS and SMB do, I haven't set up the NAS for those. I would NFS expect to be close to the FTP performance, and SMB a couple of MB/s below.

     

     

    Could you please give me a hint what kind of performance you expect?

     

    Just to make things clear: I use this NAS as btsync offsite backup. It's limitation is the upsteam bandwith of the remote internet connection, so I really don't care about performance at all. I just ordered the cheapest NAS i could find taht was mentioned as working in the NAS thread.

     

    Kind regards,

    Stephan.

  15. Hey there.

     

    I used the expression "unimportant" for quite a purpose: I tried to make you think about if it's wise to use such a highly platform specific thing, rely on it and expect others to support it, too.

    This obviously didn't happen. Something different happened instead: You feel offended. That was not intended. So sorry about that.

     

    Did you read the thread I gave you? Especially: Did you read the very post of mine I gave you?

    I think I explained quite a lot reasons why I expect btsync to cover only the very common file system features -- only those features that can be found on all file systems.

     

    You run your business on those extended file system features? Well, that's a realy brave one, imho.

     

    What happens if one of your colleges joins with a Windows computer or Linux? What happens when sharing network files via SMB or NFS? What about access to those files via smartphones, such as Android or Windows Phone? I expect even iOS to have difficulties to access those.

     

    Don't get me wrong. If you want to run your business like that, that's up to you. Even though it binds you to a very small group of capable environments. If it fits your needs, do so. If you have utilities for all kinds of jobs you need to do, I'm glad about it.

    But you definitively do know about those limitations. And you definitively do face this particular problem every couple of months with any new nice common tool that doesn't work with your restricted setup.

     

    A synchroniziation tool not covering extended attributes is not unusable in general. See the thread I linked. There are lots of people having needs of individual features. And calling your particular feature more important than others (even though they are quite compatible) is close to being presumptuous.

     

    And that's what and why I suggested in my first post: If you feel it's that important, add it to the wishlist thread.

     

    But alling it a bug and ciritical show stopper is just not true.

     

    Regards,

    Stephan.

  16. Hey there.

     

    As far as I'm concerned, I'm really happy that btsync does not try to cover every single unimportant file system feature.

     

    Since that's definitively a non-ussue for me but happens to come up every four weeks here, I suggest you to post to the wishlist thread.

     

    Have a look at this discussion, I elaborated this a lot:
    http://forum.bittorrent.com/topic/22882-destructive-sync-metadata-on-macs/?p=64350

    Kind regards,

    Stephan.

  17. Well, this isn't actually new:

    http://forum.bittorrent.com/topic/23236-upper-lowercase-issue-in-heterogenous-environments/

     

    If you think this a little bit further, you will reach this one:

    http://forum.bittorrent.com/topic/22882-destructive-sync-metadata-on-macs/

     

    The thing is: Where to stop and where to end.

    • You expect lower-case/upper-case to be handled
    • The Linux guys expect to have chown/chmod handled properly
    • The NTFS guys increase this thought by expecting to have the NTFS privileges handled properly
    • The HFS guys expect meta data to be handled properly, since on iDevices it's daily business to have valuable information in HFS meta data.
    • Then the NTFS guys start thinking "hey, we have ADS, which is something like mac meta data" and expect them to be handled properly (although ADS on NTS is rarely used), too.
    • The next step might be hardlinks to reduce file size, which is posible on various Linux file systems, HFS and NTFS.
    • The next step might be junctions (the hardlink mechanism of NTFS), which alllows imho "hardlinks of directories" too, which is kind of a dynamic mount point but not an actual hardlink in Linux terms.

    Do you get my point?

    The thing is: btsync will never be able to handle every etch case.

    And guess what: I call mixed environments etch-cases, since I expect closely connected groups (in terms of a social group, frendiship and family) to have equal environments. If you widen your group and start using btsync not as file synchronization tool but as an alternate file sharing plattform, then having heterogeneous environments might become more likely. But that's not what btsync intends to be made for.

     

    But as long as the main scenario is "each single share is (in average) shared between three to fife devices of one or two individual humans", it's really unlikely to have the mixed file system capabilities on one side and people that are completely unaware of that fact on the other.

     

    So, feel free to add your thoughts to the wishlist thread and add some explanation to it. I will not refuse calling it a valuable improvement. The btsync staff every once in a while announces that the wishlist thread is getting crawled and summarized in order to influence the products roadmap. So if so much people are bothered about this, the wishlist thread would be really the place to go.

     

    But stop calling the current situation a major bug or serious problem, since it's expected behavior and has been discussed lots of times.

     

    Regards,

    Stephan.

  18. Hey Raccoon.

     

    You most likely created a VPN setting that makes your lokal IP block (the non-VPN part) avaliable throug VPN routing, which sets up different routes to the very same subnet.

     

     

    I would gess that btsync just discovers different routs to the same host and needs to determine which one is the best. But that's not a problem of btsync as a single application but a routing problem in general. Maybe btsync isn't even aware of the fact that there are different routes. I would assume that btsync just uses plan source-TCP to target-TCP and relies on the OS to keep track on proper routing.

     

    I would suggest to start adding some metrics to your routing table that make the VPN route less valuable. See "route help" in your windows cmd window, I'm talking about the "metric" property.

    It's most likely the "route add 192.168.1.1 mask 255.255.255.0 $yourVpnEndpointIp" setting created by your VPN setup which makes your local network go through the VPN. Maybe something like "put all traffic trough VPN" as well, depending on the VPN protocol and client you use.

     

    You could give it a try create without btsync some network traffic (scp, ftp, http, whatever) which should be pure local, then turn the VPN connection off and see weather the traffic keeps going or just stops (and retries, when your desired protocol allows that, which would be the case with all of those I mentioned).

     

    I would call this kind of a local/virtual VPN loop.

     

    Regards,

    Stephan.

  19. Hey there.

     

    The first thing is: It only stores those changes that are triggered by other nodes.

    The mechanism goes like this: If a btsync instance receives a change request from another instance, the local version gets copied to the archive directory before accepting the remote changes.

     

    http://forum.bittorrent.com/topic/22176-versioning-only-works-when-a-remote-host-modifies-a-file/

     

    Regards,

    Stephan.

  20. Hey there.

     

     

    About peercdn:

     

    Well, you're talking about completely different things.

     

    This "peercdn" stuff claims to distribute resources from one visitor of your website to another through WebRTC features. That's not exaclty what WebRTC is made for, but sounds doable on the first look.

     

    I guess you think it can be compared to btsync due to the fact that in both cases there is client-only communication for "dumb payload" such as pictures and stuff.

     

    But it isn't. This "peercdn" thing completely relies on native browser features that only consist of a view JavaScript methods. That's "WebRTC", a thing which originaly was meant to do something like multi player browser games or chats. But only those browsers can play together nicely that can handle WebRTC. Not a single browser is creating its very own Webserver to distribute files to others, everything is done through WebRTC channels.

     

    And here's the critical thing which makes it different from btsync: It has its very own protocol which is way different from btsync.

     

    Sure, if you go down to "there are guys that created a booting Linux in JavaScript", then you're right. Then it can be done. But I really don't see any sense in reverse-engineering btsync an programming a btsync client in JavaScript. It doesn't make any sense in terms of both, efficiency and acceptance.

    You will never ever get a significant amount of visitors of your website to have those kind of low-level uncontrollable security holes punched that they can really use btsync protocol to share locally cached objects. That's completely out of scope.

     

    You can use existing browser extensions and features. peercdn shows an idea of how to do so. But you will never throw integrated browser communication mechanisms (like TCP socket connections to Webservers talking specific HTTP) away use your very own TCP or UDP protocol. That's for sure the point where your browser turns red and asks you if you really want to execute this highly dangerous stuff.

     

    About using btsync as CDN in general:

     

    Can be done. But this clearly is not a "client to client" thing in my eyes. It can only be part of a "backbone synchronization" thing. Say, having a couple of regular webservers and using btsync as replication strategy.

     

    I really doubt that btsync becomes a CDN itself. You always need a webserver on top of that which distributes the synchronized files to your clients.

     

     

    Regards,

    Stephan.

  21. Hey Ruud.

    If you would like to have synchronized versioning folders, you should bring this topic to the wishlist thread. Imho it's not a bug but a missing feature. So the wishlist is the right place for this.

    I think as soon as (or ... "if", since there is no public roadmap) there is partial and blockwise synchronization that takes other files than the current one into accout ("look aside synchronization" feature, I would call it, something like that has been requested in the wishlist thread) it's just tiny step ahea to synchronizing history, too, because the most of the files content should be already in place in other files.

    So: Would you mind bring this to the wishlist thread?

    Regards,

    Stephan.

  22. Hey there.

    All your linux and OS-X clients could simply stop using file names that just differ by case. Even if it's possible and even though I use Linux all day long, I consider it a bad habit having no proper naming convention. If it's human readable stuff like word files, I name my files exactly the way they would be spelled in a real sentence. My native language is german, so we have upper cases for all nouns, for example. If it's not human readable, I usually create file names that don't contain whitespaces but use lowerCamelCase. But that has to do with coding guidelines I like to stick to, I guess.

    HFS+ can be case sensitive, or can be case insensitive. Depends on mount options and/or partition settings, I think. I know that there are are both kinds of.

    I know that there are other programs, e.g. some (not so old) Photoshop versions that just can't handel those. So it's not only a problem of btsync but seems to be kind of common in the iWorld.

    You could simply switch to all case insensitive file systems on all your computers. Think about e.g. mobile phones where FAT is very common even if the phone itselfe (Android, in my case) is aware of case sensitivity.

    Have a look at this one, there's a little more then just case sensitivity when it comes to different file sytems:

    Regards,

    Stephan.

  23. As far as I know, boxcryptor (version 1) is "just" encfs.

    Regarding to some online receptions, it's a little faster than e.g. encfs4win. Since encfs4win relies on Dokan, which seems to have stopped development, I think using boxcryptor for the long therm is a nice thing.

    Since boxcryptor version 2 has a couple of changes that make it incompatible with encfs, I would only use it if I needed the improved multi user features in business environments. That's the main deal of boxcryptor 2, imho: Not a single locally stored password but a provided privilege system. On the one side this makes you depend on the boxcryptor company. On the other hand you can have shared encrypted stuff with partial access.

    I would go for boxcryptor 1.

    Regards,

    Stephan.

  24. Hey there.

    What's the thing with VirtualBox images? Are there any further details about what gets corrupt and why?

    I would expect btsync to synchronize "bitwise". Even if there's a block based delta mechanism, the file content and naming of source and target should be 100% identically.

    There's only one thing that might be different, that's privileges.

    I don't know what's going to happen with files that are read-write-open by any process but some kind of "hidden". I don't know if there is such a thing, but maybe a process running as root can open a file handle without triggering a lock on it. That would be, imho, the only real scenario where btsync could create corrupt syncs. Assuming that btsync isn't corrupt in some way internally, of course.

    So, I would go for creating a local backup folder. Just copy the your VirtualBox images to that backup destination and after that use btsync to synchronize onsite and offsite backup destinations.

    There's software out that that does exactly that: Create backups of your VMs to e.g. NAS and ontop of that introduce versioning to them.

    That's the way I am thinking about. Not for VirtualBox but for VMware ESX. I have a single ESX with local 4 disks RAID10 SSDs. The VMs get copied every night to a 3 disks RAID5 SATA-HDD NFS backup storage. That's the current thing, no btsync involved. My plan is to set up another 3 disks RAID5 SATA HDD NFS on another location and allow btsync to copy the data. But btsync should never deal with live source VMDK files.

    Regards,

    Stephan.