kos13

Latest Sync Build: 1.1.70

Recommended Posts

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

Share this post


Link to post
Share on other sites

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 worked

but then I jumped at it and it broke again. I've sent logs your way.

Share this post


Link to post
Share on other sites

Hi

Unfortunately 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 :-)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Logs will not make our life harder, so if you are able just submit them. You have to re-add folder on both machines.

Share this post


Link to post
Share on other sites

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"

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Using http://syncapp.bitto...4-1.1.27.tar.gz

GUI via https isn't working :(

http works, but I want https

The 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.

Share this post


Link to post
Share on other sites

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"?

Share this post


Link to post
Share on other sites

- .SyncTrash is renamed to SyncArchive

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.

Share this post


Link to post
Share on other sites

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.)

Share this post


Link to post
Share on other sites

(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.

Share this post


Link to post
Share on other sites

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"!

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Using http://syncapp.bitto...4-1.1.27.tar.gz

GUI via https isn't working :(

http works, but I want https

The 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/ ...)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.