upcboy Posted July 11, 2013 Report Share Posted July 11, 2013 We have new build.is there not an new Android update? (there is not even an APK listed is why i asked) Edit: I Jumped the Gun its answered else where that the Android version will be delayed Link to comment Share on other sites More sharing options...
Disappointed Cat Posted July 11, 2013 Report Share Posted July 11, 2013 New builds are coming sooner and sooner. The read-only stickiness and the re-indexing after restart are indeed gone and I like the ergonomic GUI changes.I also tested renaming large directories currently in sync which at first workedbut then I jumped at it and it broke again. I've sent logs your way. Link to comment Share on other sites More sharing options...
atte Posted July 11, 2013 Report Share Posted July 11, 2013 HiUnfortunately this also crashes on my Debian install/geode CPU.Could you try compiling with either "-march=geode" or "-march=i486 -mtune=geode" (gcc options)? Maybe "-march=i386 -mtune=geode" would make the i386 and glibc23_i386 builds work on everything they work on now + the geode, if you want to keep binaries to a minimum...I guess the best would be to use "-march=geode" and make it available as a seperate download...Hope you're willing to give this a try :-) Link to comment Share on other sites More sharing options...
krtaylor Posted July 11, 2013 Report Share Posted July 11, 2013 Question - build 33 addresses issues with "sync stuck." Does it fix those issues simply by being installed? Or do you have to delete and re-create the stuck share? I have several in that situation, and I've upgraded to 33 but they seem still to be stuck. Link to comment Share on other sites More sharing options...
kos13 Posted July 11, 2013 Author Report Share Posted July 11, 2013 You have to re-add folders. There were issues with DB on Windows machines. Link to comment Share on other sites More sharing options...
krtaylor Posted July 11, 2013 Report Share Posted July 11, 2013 Maybe this belongs in its own thread, but in a multi-node setup, do you have to drop and re-add the affected folder on all machines? Or just the one showing as stuck? I'm trying with just the stuck node and it doesn't seem to always fix the problem all the way. Do you want the logs? Link to comment Share on other sites More sharing options...
kos13 Posted July 11, 2013 Author Report Share Posted July 11, 2013 Logs will not make our life harder, so if you are able just submit them. You have to re-add folder on both machines. Link to comment Share on other sites More sharing options...
sergey@bt Posted July 12, 2013 Report Share Posted July 12, 2013 Latest Android build is available at: http://syncapp.bittorrent.com/1.1.33/BTSync-1.1.16.apkChanges:- Correctly handle disabled 'Use cellular data' option (previous version could send some traffic)- Added 'Pause' for syncing folders- Added backup of application settings- Battery usage improvements- Updated UI- Various bug fixes Link to comment Share on other sites More sharing options...
yield Posted July 12, 2013 Report Share Posted July 12, 2013 Build 1.1.30 on FreeBSD AMD 64 worked without problems but with build 1.1.33./btsync --config btsync.conf --nodaemon/libexec/ld-elf.so.1: /usr/home/yield/btsync/btsync: Undefined symbol "posix_fallocate" Link to comment Share on other sites More sharing options...
sts Posted July 13, 2013 Report Share Posted July 13, 2013 Build 1.1.30 on FreeBSD AMD 64 worked without problems but with build 1.1.33./btsync --config btsync.conf --nodaemon/libexec/ld-elf.so.1: /usr/home/yield/btsync/btsync: Undefined symbol "posix_fallocate"strange, it works fine here on FreeBSD AMD64 though i am not using the nodaemon mode. Link to comment Share on other sites More sharing options...
DonCamilo Posted July 14, 2013 Report Share Posted July 14, 2013 Hi,Shouldn't I get autoupdate from 1.1.27? Link to comment Share on other sites More sharing options...
GreatMarko Posted July 14, 2013 Report Share Posted July 14, 2013 Shouldn't I get autoupdate from 1.1.27?Yes, eventually - but if you want it sooner, use the link in the first post of this thread Link to comment Share on other sites More sharing options...
affinity Posted July 14, 2013 Report Share Posted July 14, 2013 Using http://syncapp.bitto...4-1.1.27.tar.gzGUI via https isn't working http works, but I want httpsThe 1.0.34 version runs https without any problems....An error occurred during a connection to nnn.nnn.nnn.nnn:8888.SSL received a record that exceeded the maximum permissible length.(Error code: ssl_error_rx_record_too_long)Now using 1.1.33 -- same problem, no https on Linux X64 version. Link to comment Share on other sites More sharing options...
kos13 Posted July 15, 2013 Author Report Share Posted July 15, 2013 New build is 1.1.40 Link to comment Share on other sites More sharing options...
atte Posted July 15, 2013 Report Share Posted July 15, 2013 Still crashes on my geode CPU. Did you have time to look into the logs I send you and/or try building a binary with "-march=geode"? Link to comment Share on other sites More sharing options...
Disappointed Cat Posted July 15, 2013 Report Share Posted July 15, 2013 - .SyncTrash is renamed to SyncArchiveI don't think this was a good idea. At least for me this is very inconvenient.Please rename it to .SyncArchive or give the option to do so.Also .SynTrash folders remained as they were and now we have to manually rename them everywhere. Link to comment Share on other sites More sharing options...
Shot2 Posted July 15, 2013 Report Share Posted July 15, 2013 I don't think this was a good idea. At least for me this is very inconvenient.Please rename it to .SyncArchive or give the option to do so.Also .SynTrash folders remained as they were and now we have to manually rename them everywhere.+1, this is a terribad idea. Especially now that it is no longer hidden by default under Nux. At least there should be a way to customize the location for "trash", and/or disable it altogether.The cleanest way would be NOT to mix app-specific metadata and trash/outdated files within live, current, potentially publicly-exposed data. A centralized DB (in %APPDATA% under Win, under /usr or e.g. user .config dir for GNU Linux) would be the way to go.(Sticking with 1.1.33 for the time being until it gets eventually fixed.) Link to comment Share on other sites More sharing options...
prestonwii Posted July 15, 2013 Report Share Posted July 15, 2013 (Sticking with 1.1.33 for the time being until it gets eventually fixed.)Hmm...I actually like this change, but maybe it is because of what I'm using the software for. I like the old version being synced across all of my clients because if I make a bad change, I can recover it for any client. The change is simply integrating the trash and the archiving together into a single thing (which they basically are). I don't see how a (dot) at the beginning of the file makes a difference, because it is simply a UI thing (the shell hides the file for you) and not a functional thing. I do think it would be nice to disable trash/versioning and I think it is possible by setting the sync_trash_ttl to 0. Link to comment Share on other sites More sharing options...
GreatMarko Posted July 15, 2013 Report Share Posted July 15, 2013 I don't see how a (dot) at the beginning of the file makes a difference, because it is simply a UI thing (the shell hides the file for you) and not a functional thing.It's not just about "hiding" files (for example, on Windows, .files are not hidden by default)... it's more to do with the default sort order of file/folder lists, which for most users will be alphabetically, meaning that files/folders starting with a "." will appear right at the top of the list. If "SyncArchive" doesn't start with a dot, it'll appear much further down the file/folder list, making it very easy to overlook, and potentially inadvertently delete! ...that's why it would make more sense for it to start with with a "." just like .SyncIgnore and .SyncID do, so that it appears near the top of directory listings!!I do think it would be nice to disable trash/versioning and I think it is possible by setting the sync_trash_ttl to 0.You can simply change the per-folder "Store deleted files in SyncArchive" setting to "off"! Link to comment Share on other sites More sharing options...
Shot2 Posted July 15, 2013 Report Share Posted July 15, 2013 Hmm...I actually like this change, but maybe it is because of what I'm using the software for. I like the old version being synced across all of my clients because if I make a bad change, I can recover it for any client. The change is simply integrating the trash and the archiving together into a single thing (which they basically are). I don't see how a (dot) at the beginning of the file makes a difference, because it is simply a UI thing (the shell hides the file for you) and not a functional thing. I do think it would be nice to disable trash/versioning and I think it is possible by setting the sync_trash_ttl to 0.It makes a difference because the .Sync[Whatever] file or dir is no longer 1/ hidden 2/ interpreted as a special file by other software accessing the directory tree, e.g. a web server. Makes maintaining a server needlessly more complicated - having to define special rules for these BTsync-proprietary files. Image people downloading up-to-date files via, let's say, FTP or HTTP, they will stumble upon that "SyncArchive" dir and grab it for nothing (either because it's empty, or because it contains gigabytes of deprecated/outdated/buggy/temporary files). It's no definitive deal breaker, but it's imho a weird and rather unflexible design decision.Worse: just found that upon restarting btsync, and even though all shared folders are explicitely configured as "Do not use the Sync trash", that damn (and explicitely configured as "do not use, you're useless, keep away of my hierarchy!") folder gets recreated... So now we have to reconfigure servers to forcibly hide/do not serve a new filename (until the next change by btsync devs) + run a cron task to forcibly delete Sync[Whatever] folders Link to comment Share on other sites More sharing options...
GreatMarko Posted July 15, 2013 Report Share Posted July 15, 2013 It makes a difference because the .Sync[Whatever] file or dir is no longer 1/ hidden 2/ interpreted as a special file by other software accessing the directory tree, e.g. a web server. Makes maintaining a server needlessly more complicated - having to define special rules for these BTsync-proprietary files. Image people downloading up-to-date files via, let's say, FTP or HTTP, they will stumble upon that "SyncArchive" dir and grab it for nothing. It's no deal breaker, but it's imho a weird and rather unflexible design decision.Agreed!Worse: just found that upon restarting btsync, and even though all shared folders are explicitely configured as "Do not use the Sync trash", that damn (and explicitely configured as "do not use, you're useless, keep away of my hierarchy!") folder gets recreated...Yeah, Sync used to do the same with .SyncTrash folders - even if you'd configured Sync not to delete to .SyncTrash, the folder itself would still be created/present. Link to comment Share on other sites More sharing options...
prestonwii Posted July 15, 2013 Report Share Posted July 15, 2013 It's not just about "hiding" files (for example, on Windows, .files are not hidden by default)... it's more to do with the default sort order of file/folder lists, which for most users will be alphabetically, meaning that files/folders starting with a "." will appear right at the top of the list. If "SyncArchive" doesn't start with a dot, it'll appear much further down the file/folder list, making it very easy to overlook, and potentially inadvertently delete! ...that's why it would make more sense for it to start with with a "." just like .SyncIgnore and .SyncID do, so that it appears near the top of directory listings!!You can simply change the per-folder "Store deleted files in SyncArchive" setting to "off"!Understandable. Sorting make a bit more sense to me and it makes me wonder what happens if you delete the "SyncArchive" folder considering that is where deleted stuff is kept. I'd almost think you'd delete it and all clients should just replace it, but I'm not sure. I had also forgotten about the per folder options. I still don't see this issue a deal breaker and I've upgraded to the newest version. So far, I find this software fantastic and I'm happy with how quickly it is evolving. Link to comment Share on other sites More sharing options...
affinity Posted July 15, 2013 Report Share Posted July 15, 2013 Using http://syncapp.bitto...4-1.1.27.tar.gzGUI via https isn't working http works, but I want httpsThe 1.0.34 version runs https without any problems....An error occurred during a connection to nnn.nnn.nnn.nnn:8888.SSL received a record that exceeded the maximum permissible length.(Error code: ssl_error_rx_record_too_long)Now using 1.1.40 -- same problem, no https on Linux X64 version, please fix this!I do not want http access, I want only https -- it used to be possible (without resorting to tunnel /tricks/ ...) Link to comment Share on other sites More sharing options...
affinity Posted July 15, 2013 Report Share Posted July 15, 2013 Definitely also prefer .SyncArchive over SyncArchive too -- better still, name the folders ourselves...Actually I would also prefer to see the .SyncArchive data remain there indefinitely AND be under my own control, not that of ALL users of a common Sync that is world writeable by anyone with the secret.The "sync_trash_ttl" -- that needs a default, 30 days is fine, it needs 0 for no trash and say 99999 for never clear or something like that. Link to comment Share on other sites More sharing options...
unsignedint Posted July 15, 2013 Report Share Posted July 15, 2013 I'd like to suggest having QR code to Android build on distribution page. It's much easier to sideload the application that way!(I usually end up using goo.gl to generate one myself like http://goo.gl/#analytics/goo.gl/nysrf/all_time Link to comment Share on other sites More sharing options...
Recommended Posts