Latest Sync Build: 1.1.70


kos13
 Share

Recommended Posts

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

Link to comment
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.

Link to comment
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?

Link to comment
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.

Link to comment
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.

Link to comment
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.)

Link to comment
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.

Link to comment
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"!

Link to comment
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 :)

Link to comment
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.

Link to comment
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.

Link to comment
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/ ...)

Link to comment
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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share