nils
-
Posts
238 -
Joined
-
Last visited
-
Days Won
5
Posts posted by nils
-
-
First of all, sync should still work, because the other two nodes (OS X, Win7) will forward changes from/to the HP sever and the Win8.1 desktop.
It is not clear, what network setup you have, where are all the devices? same network, behind routers (NAT), public IP, VPN etc
-
Include a commandline option to extract the configuration from a btsync installation. E.g. I run btsync without any specific config, therefore btsync takes care of the config for me. After a while, I would like to tinker with the settings in a config file, which is where an "export" of the settings into a human readable file would be nice. With this exported version, I could then either use it to run the current btsync, or take it away to replicate it elsewhere.
-
In iOS it means, that with automatic sync, all changes will propagate to the iOS device i.e. download/delete files appropriately. Automatic sync OFF should leave everything as it is, and you can download files that are available.
iOS's implementation for an RW master node is not functional, i.e. if I delete a file, it only gets deleted locally on my iOS device and not on the other networked nodes.
1) Android does not have this bug, which means it can delete things
2) It's buggy
3) Automatic sync is only one-way?
-
The behaviour you describe sounds, as if the Android devices have the master secret, i.e. read-write access to the share. On master shares, deleted files will also propagate to all other connected devices of that share. If you access the share with a read-only secret, then the deletion of a file on a RO device will not propagate through to all other devices.
On iOS, the client cannot delete files in a share, which is a bug if I want it to be used as a read-write node like any desktop and command line version. I have no Android device, but by the sounds of it you have set it up as a read-write device and therefore will delete files in the share permanently.
-
All available files will be synced among all online peers.
(May be not entirely correct, if only peers with read-only secret are available, but between read-write secret peers, it will work.)
The RO devices will sync between each other, if one RO device was synced with the RW device.
-
Hi,
The way I see it, it seems this use case is out of scope, because it is not related to a networked synchronisation solution. For local backups, rsync might be a good alternative, or for Linux even cp -a. If the script needs to act upon changes, then https://github.com/mattes/autorsync might be worth looking into. HTH
-
Hello,
I do not think that this is on the developers roadmap, because file corruption is not a feature of file synchronisation. The feature you are looking for can be achieved by a) use of a file system (ZFS?) or
by introducing more nodes, replicating the data. The .SyncArchive employs a minimalistic versioning by appending numbers to the file names, if that would help. -
Hi longplay,
I am not quite sure I understand, there are two scenarios I can think of:
1) Your laptop btsync client is set up read only, which means changes will not propagate back to the raspberry pi/android tablet or
2) more likely: the user that is running btsync on your laptop is not the same you access your files with.
In case 1) you would need to acquire the master secret from the raspberry pi shared folder and in case 2) you should run btsync as the user who accesses the files. I hope this helps.
-
It sounds like a 2FA to me, might be worth looking into, especially if people send secrets via email and would want their BTsync share to be safe.
-
Hello,
BTsync does not have an option to turn off overwriting of files with the same filename. Furthermore, this would not be syncing after all, maybe rsync and the archival function would be better suited for your use case. The only option you would have with BTsync is the .SyncArchive folder, which keeps overwritten files up to a certain number of days, combined with a script acting upon changes to the archive folder could be used as well.
Maybe a simple directory structure with "YYYY-MM-DD" for each corresponding date would be more suitable?
-
@GreatMarko thank you for the clarification. I have not relied on .SyncArchive so far, as I use ZFS snapshots where possible on my nodes.
-
IMHO BTsync is not meant to replace archival backups. The .SyncArchive does not indicate when a file was moved there or any versioning of a file, apart from this one copy.
I would recommend either using an additional tool like rsync for archiving the data or ZFS to take snapshots, allowing you to backup and retrieve the data at the specified backup points.
-
Make detailed information on connected devices of a share available in GUI/Web-UI:
- IP and Port
- Read only, Master, One time node
- max up/download recorded speeds
- BTsync version running
- Files left to be synced
-
Hi Gerald,
The only icon I have encountered on the Mac desktop client is the cloud, which displays connections are via the relay. The two way arrows appear in the web-ui only on unix/linux.
-
It depends on your zip file implementation and how changes are being saved/how the file changes after you encrypt it again.
I would recommend EncFS, which does pretty much what you want (encryption) but every file is encrypted on its own, making it nice and easy for btsync to see which file was changed. Although it could then still be the same issue, because every file gets encrypted, theoretically changing the whole file depending on how EncFS does it internally. One benefit though: it would do so atomically for each file, and reduce any overhead in the worst case.
-
Hi florian,
1. When I set up a new share, the following entries are by default in the .SyncIgnore file on OS X:
# OS generated files #.DS_Store.DS_Store?._*.Spotlight-V100.TrashesIcon?ehthumbs.dbdesktop.iniThumbs.db
Maybe some of those rules catch some of your files...
2. The user running btsync should have at least read permissions to the files you want to sync. A brute-force method to make it so would be
chmod -R o+r /your/share/folder
which would result in the the permissions for other to have read rights recursively. Be warned, as this makes all the files readable to anyone on that system in the specific share.
3. I am not sure if btsync logs them, but I remember seeing two separate threads on this topic.
HTH
-
1. Take a peek at the .SyncIgnore in your share folder, maybe a rule disregards some of your files.
2. Permissions can be a problem for btsync.
3. Some international characters such as ß and é in filenames are troublemakers at the moment and the corresponding files are not synced either.
-
Just noticed a few lines up in the sync.log that there is a file with a <DF> in the name (highlighted, when I view sync.log with less). When I view sync.log with emacs it's this character: ß and when I look at the actual file on the original machine (a linux box), it has a question mark in the name. I'm not sure where that came from, but could that be the problem? It does not exist on the Mac, like it never actually go copied over.
Wow! Getting off topic now, but I had synced the same folder using Spideroak before, and I just looked at the destination folder and that file with the ? in the name is completely missing. Spideroak just silently skipped right over it, apparently. I guess other apps have problems with that filename too...
The same problem was reported by some other users in this forum, citing that using the french accents in filenames caused trouble as well. For the time being, it seems best to stick with the US alphabet without any localised characters.
-
1. Some routers report opened ports with UPnP/NAT and the respective IP address they are used with in your LAN one some info page. Another option is programs that will get the port mappings from a router, e.g. http://sourceforge.net/projects/upnp-portmapper/.
2. The magic word to make it so the same IP is used is 'static lease'. I have OpenWRT running on my router and set up all my devices to obtain always the same IP address. The devices are recognised by their MAC addresses.
-
Hmm, the file does not give any indication on what is going on. You can have a more verbose output in sync.log if you check "Enable Debug Logging" in the menu options. Maybe something then crops up, which goes unnoticed otherwise.
And then, does it always crash with the Documents folder being last? Maybe a new file in there creates problems?
-
Hi,
One other place to look for information is the sync.log file in the library folder:
/Users/<yournamehere>/Library/Application Support/BitTorrent Sync
Maybe have a look at suspicious entries and/or attach to a post here as well.
-
Hi Joe,
Regarding the default settings, you could turn off DHT, tracker and relay server and turn on search LAN, if you only intend to use it within a LAN, maybe even insert your hosts in the predefined hosts section.
@deem: I use the x64 version of btsync and this the output of file I get on the btsync executable, so I think BTsync is 64 bit capable on supported platforms, thereby expanding the maximum number.
btsync: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped
-
My wishlist:
Desktop:
- fix QR code display for large secrets in OS X (have not tested other desktop versions)
- Add ability to create large secrets integrating commands such as "head -c 1024 /dev/random | base64"
- "Backport" iOS style downloading of individual files instead of the whole share
- Add quick option to share files as in "Send files" on mobile version.
- Add QR code reading capability
- Add Write-only secret where it is not possible to delete any files on the other nodes
- Add ability to configure .SyncIgnore
iOS:
- Fix/Add ability to delete files permanently from shares and/or create write-only secret or option to select behaviour
- Include more config options to fine tune shares as in the desktop version
- Add capability to set up own shares on a mobile and share QR code/secrets with other mobile apps
-
It is not surprising, if ? is interpreted as wildcard in the way of "any one character". So Icon? in .SyncIgnore would match Icons, Icon?,, IconC, etc, but not IconCache, IconStore, etc. The current "inconvenience" is, that the .SyncIgnore file is not accessible through the UI and therefore people might be unaware of it, as the file is not shown in many operating systems, unless using the commandline.
by introducing more nodes, replicating the data. The .SyncArchive employs a minimalistic versioning by appending numbers to the file names, if that would help.
How much files btsync can deal with.
in Sync General Discussion
Posted
I just quote from here http://forum.bittorrent.com/topic/23802-syncing-600gb-10-million-files-recommend-settings/ :
From unofficial FAQ we know that "if you're monitoring/syncing 1 million files, you will need around 300-400 MB of free memory". BTSync is 32-bit, so, it can only use ~2 GB of RAM. Therefore, the maximum amount of files is limited to ~6 million.