Doc Green

RomanZ, I will collect the logs as soon as possible. Funny thing is, that the device lists itself twice as a peer. All other devices only list it once. So long Doc Green

Hi, this is definitely not a pressing matter, just an observation: since I installed version 1.3.77 I have one device, which will list itself twice under the connected tab in its own webui. I just upgraded to version 1.3.80 but it is still listing itself. Before it states its name it displays the IP adresses. This device has multiple addresses and the tab shows two of them. So my best guess is, that btsync is a little bit confused by the addresses, althoug it is not listing itself for all available IP addresses. Additionally it keeps saying that these devices need to completly sync. Thankfully it does not do anything, just displays itself. For the moment I cannot configure debug log on the machine, but maybe it is enough to draw some conclusions. The device is a Sempron machine, with debian i386 installed, the version of sync is 1.3.80, build is linux i386. So long Doc

I am actually using it in the that way for some sets of my private files, and it is pretty handy for small office files and so on. Still, I can think of scenarios where this will not suffice as a backup, although to my mind these scenarios are a negligible risk in a private environment. Physical harm can be prevented by offsite Sync instances. Trojans or viruses attacking my datas integrity on all devices seems to be a low risk either at the moment. On the other hand Sync is still beta so I would not fully trust it. Think of the reappearing deleted files, files not fully synced or conflicting. It happens very rarely, but you would not want to verify the datas integrity all the time. And for frequently modified folders, it is hard to find the version you want to revert to. In addtion I am having an always on device, it keeps all the versions of the files in Synctrash, but not everybody wants that or can afford that. For now I use it as an addtional backup service, it serves its purpose as a first backup instance and proved to be very useful.I have already encountered a hdd crash on a laptop since I am using Sync. I just had to install a new hdd, reinstall the OS (in this case using an image of a fresh installation), enter the secrets of my shares and I was good to go again in less then an hour. I did not have to deal with older file versions or old backups. No other solution I know of would have been that easy and painless, Dropbox and the others out there would charge a lot of money for the amount of data and it would have been a LOT slower. However I still use offline backups on external storage devices, better save then sorry So long Doc

This is not entirely true. A server or one installation of Sync with a static IP or a domain is sufficient. Set your folders to use that static address. That instance will tell all other instances with the corresponding secret the IP addresses of the partnering clients so they can connect to each other. If you are unable to get a direct connection to a client, that instance will relay the data somewhat, because it gets the data first and distributes it again. Of course it needs all the secrets and sufficient disk space and you should be able to connect to it directly. So one instance and its public address is all you need to get it working without the help of Bittorrent Inc. So long Doc Green

Lets look at this again from a different angle: Every filesystem is designed to handle access to data on it. You want the filesystem to find and manage your data. There is a commonly known method to organize data by metadata which is basic and can be found in mostly every filesystem: names for files and maybe folders. This is pretty basic metadata attached to mostly every bit on a harddrive or whatever technology you use to store data. There can be additional data attached to it, also very commonly used is date of creation, last access/change and so on. So this is pretty basic stuff nowadays and they are handled differently by different filesystems but they are common. And usually there are similar handlers given by the OS to a program to gain access to the actual data. What is not common: what characters are available for this metadata, upper and lower case is already a difficult problem and is still unsolved. Furthermore this is handled differently by different filesystems it is even handled differently by the same filesystems on different architectures or implementations/versions, the journaling functions of HFS+ are not completely available on all Linux systems or its implementations if available at all. This is also true for an Apple scenario as you have pointed out. Why is that a problem at all if you use a Apple/Linux/Windows environment only? You have to make sure every Apple/Linux/Windows machine has the same set of capabilities, if you dont you will lose metadata at some point for sure. That renders such a capability useless if you strongly rely on it. Of course you can check for these special setups before starting a sync. Then you have to decide what you want to sync to another node if yours is not capable of that metadata. Should Sync fill all the missing metadata fields with zeros leave them completely blank? Ask the other node if it has any clue from prior versions of the file and so on... That is absolutely solvable for homogeneous environments, but gets clearly very complex in herogeneous environments. At least you need some basic level of agreement on all participating machines what information can be exchanged without any kind of misunderstanding/corruption of data. At this point Sync or any other similar software development needs to decide what kind of filesystem specifics are worth to implement. And you have to specify a policy what to do with unsupported data. How difficult such a policy is, becomes obvious if you look at the update policy of Sync. A wrongly set timestamp on one node can sync old data and overwrite the legitimate newer data on another one. What happens if you use an old version of OSX where larger than 128kb extended attributes are not available and cannot be interpreted? It seems obvious to cover the broadest and most common use of filesystems/data (name, date, size), any specific extended attribute or whatever you call it makes it harder to create a solution for a greater range of devices/systems. Any additional information provided by a filesystem is outside of the file itself and needs an additional piece of software to compute it. It has absolutely nothing to do with the stored data in a file and is specific to a filesystem. Because of these considerations I believe one should not hurry with the implementation of special features of a single filesystem especially if they are not even a fixed featureset in a given OS environment. One should better have an eye on all use case scenarios and look into a solution which is most fitting for them all. So even if Dropbox is capable of solving these very special use cases, it does not cover them all for sure. Extended attributes or file permissions are not transferred completely but maybe someone really needs this, I really wish I could use sync for that too. On the other hand there are solutions for such use cases already available AFP/NFS/SMB you name it and there are reasons why they are more centralized approaches: you need someone to enforce security policies, enrich data with additional metadata and manage all that. There is a reason why document management systems like Alfresco rely on central servers and special programs. They were specially designed to manage documents/files, Sync at the moment takes care of the storage of files not how you wish them to be handled by your users. And there is still enough work to be done to cover that function for a non-beta level. So why not focus on that or a while? So long Doc Green

Hello, I have to agree with Firon and to some extend with Goli. I do not believe that extended attributes or any other metadata added to files through specific file system features should be synced at all. There are too many features on different platforms. The core capabilities of Sync should be enhanced more and the whole solution should focus on more stability and reliability. Whats the big reason to support special features of a given filesystem like HFS+ while there are other filesystems with other nice capabilities. The main reason for using Sync is its decentralized synchronisation of files and folders. If you would want to redistribute complete filesystems you should think of more centralized solutions. Don't get me wrong I see your need for these features, but I think you should really consider something different. For example what do you plan to do if another OS gets involved like Windows or Linux with its great variety of filesystems? What happens if one of your machines corrupts its filesystem and starts to sync it all to the rest? There are a lot of other solutions to implement extra metadata like full document management systems which take care of stuff like that. So to me it is a very bad idea to implement special features of a single filesystem, not just for compatibility reasons more for your own data safety. So long Doc Green

Hi dontpanicbaby, I have done some testing a while ago. Since the new 1.2x versions I just have done a quick file creation test on a x86 machine. Before creating the files btsync was idling as you would expect it, with about 10MB usage of RAM. After the creation of 1,000,000 dummy files it consumed about 450MB. Of course the files are nearly empty, so indexing was pretty fast. You should increase the rescan interval, because it will get stuck in scanning all the time. Also the database file consumed about 550MB. So yes you can easily handle several millions of files. You only need RAM. So long Doc Green

Hi supermooshman, I am actually doing the same thing at the moment. There is no way to revoke someones permission at the moment. I hope there will be a solution, so you can revoke one persons secret without changing it on all the other devices, that is quite unhandy. However I plan to play with the new API once i receive the API key, it should give me the possibility to remotely change secrets on all running devices with webgui enabled via some scripts. At the moment I dont see how you can do such a thing in an unsecure environment (device outside the companys network or on mobile devices). And yes you can turn off your computer after sync with another machine is completed. I use it this way at the company and at home. I have a device/server always runnning in the LAN. These always on instances take care of updating other clients when they come online. It is also pretty handy for transfers over slow internet connections. So long Doc Green

Sync uses the interval to make sure no file changes slipped its usual mechanism of detecting them. Usually it uses the capabilities of the OS to detect file changes as far as I know. This works really stable. I have set the interval to one week and it works like a charm since the last update of Sync. I suggest you just give a highe interval a try. My devices show exact same behaviour, so there is no difference between USB drives, internal HDDs or a NAS. So long Doc Green

I did some testing, the behaviour is there and I tend to agree, that this might be a problem. But not a serious one to my mind. First of all SyncArchive prevents complete deletion of files. Second it is not true that Sync is simply silent. It does give you a hint via the notifcation messages and it shows changes in the history. It would be nicer if it sets off some kind of alarm, but for sure your data is not simply lost. This is as mentioned an issue of the OS and its there for a ridiculously long time, not just causing problems with Sync. So long Doc Green

You can execute btsync even with the same user. To achieve that you create a seperate config file for each instance. Just do a "btsync --dump-sample-config" on console put the output into a seperate file, change the port of the webgui, maybe set a static listening port and change the name of the device. You should also change the location of the pid file. Execute "btsync --config btsync-config-file". Thats it. So long Doc Green

Because this is a lacking feature I came up with a script solution which monitors the log file. Whenever the statement "addsyncfolder" occurs, the script tests the existence of this folder, if it does not it will create it. Basically you can only create folders this way, but you cannot delete them. But for testing purposes it is enough and it is somewhat conivient. It is not a nice solution but works quite well for now. #!/bin/bash tail -f /home/Sync/.sync/sync.log| while read line; do echo $line |grep addsyncfolder > /dev/null 2>&1 if [[ $? == 0 ]] ; then NEWDIR=`echo $line|grep -o addsyncfolder\&name.*secret `; NEWDIR=`echo $NEWDIR|sed -e 's/addsyncfolder\&name=//g'| sed -e 's/%2F/\//g'|sed -e 's/\&secret//g'`; if [[ ! -e /home/Sync/$NEWDIR ]] ; then mkdir /home/Sync/$NEWDIR fi fi doneMaybe it can help you too. So long Doc Green

Yes, the folder rescan should detect all changes which failed for whatever reason to trigger a file system event. I have set the time between 2 folder rescans to one week on my central Sync instance. I guess you could probably set an unlimited interval, if you only access the files on a central server through Bittorrent Sync. So long Doc Green