fnordsensei
-
Posts
44 -
Joined
-
Last visited
-
Days Won
2
Posts posted by fnordsensei
-
-
No, there's literally no change in content at all from before 1.1.12 and after. I have neither been adding nor subtracting any files, all I did was to update the client.
-
In the latest update, it seems that read only shares don't hash. The last share in the attached image is a share that has several gigabytes of data in it, but it doesn't get hashed by BT Sync.
-
When file path can not be created on target OS (incompatible file system characters), it will be skipped from sync;
Is this a stopgap solution? Just skipping could lead to some seriously broken stuff. Perhaps there should at least be a list somewhere in the UI that tells you what is not being synced, and why, so that you can change it? In particular, the sending machine needs to be informed of this so that they can choose to fix those files and folders.
-
Since we are limited to a 100 test users for iOS (thank you Apple) I would like to make sure that all contributors to the forum will get invitations. Please reply to this topic and I will make sure that you are included.
If you need Android application, subscribe to the list. We don't have any limitation there (thank you Google)
EDIT: If you are lucky to have 5GHz WiFi on your mobile, consider upgrading your WAP to support it. Sync will squeeze every bit out of it.
Reply!
-
One thing is for sure, Sync needs to handle the error better. It should skip the files, and log the issue, and move on, and let you know later what it didn't sync and why. Instead it appears to waste bandwidth by continually trying to transfer the files. That is very bad behavior.
I think maybe it was question marks, or perhaps quotes. Anyway, I'm sure it'll be worked out. Since files can be identified via hash, it should be very possible to have the same file have slightly different names on different computers, and still be identified as the same file.
Don't worry though, the bug has been reported and I've received a confirmation that it's lodged in their Zendesk instance.
-
Indeed, 134 it is!
The log does report errors, in particular:
The directory name is invalid.I think maybe the directory name contains a character that is valid on OS X, but invalid on Windows. The share is read-only, originates on OS X, and is copied to Windows. I suppose the continuous download could be BT Sync retrying the download, forever.
I've emailed the error log.
-
Hello!
I've run into a weird problem where it seems that BT Sync keeps sending data forever, but the data is not actually used for anything.
It'll keep receiving like this forever. Usually it eats 1-3mb/s of my bandwidth, it's unusually slow now for some reason. Note that the counter down to the right says that nothing is being transmitted.
If I look at the shared folder, it is stuck at having 169.6 mb to go, forever.
So, what's happening here?
-
It is much better if you have local clock synchronized, which is an actual right way. Sync will deal with the case if clock is not synchronized between computers, but this will complicate things a little bit.
Answering your question: Sync will behave correctly if your clocks are not synchronized, it will detect these cases.
That is good to know, thanks!
Yes of course, I wouldn't be keeping my clocks unsynchronized on purpose.
-
It will have a different timestamp that is set by OS (nothing to do with Sync) and Sync will detect that content is similar just changed timestamp, so this information will be propagated to all nodes. I don't see any problem here, or I just don't understand what you are tying to say.
So does this mean that I can accidentally overwrite all other peers if my local clock is set in the future? Or similarly, I can get all my data overwritten if my local clock is set in the past (which can happen after a CMOS reset for example)?
-
Of course this will work only if we work with timestamps only.
Quick question: does BT Sync use local time as a timestamp, or are all files timestamped using some centralized chronometric service?
-
…the actual "hash" of all the files within the folder (which is what BitTorrent Sync is monitoring in real time) is stored elsewhere (i.e. on Windows it's under %AppData%/Roaming/BitTorrent Sync)…
It seems to me that this would be way more portable if the hashes were stored along with the .syncID. That way, if the files, hashes and syncID disappeared all at the same time, a drive has probably been unplugged. But if the hash and syncID is there, but the file is not, it has probably been deleted.
-
Alright, thanks for your overwhelming insight ;-)
I tried it out in practice, and it seems that using a single folder to sync to regardless of operating system booted seems to work. Of course, I can't be sure as there may be issues I'm not aware of.
-
If I have more than one operating system (Win/OSX/Linux) running on the same machine, is it safe it allow them to sync to the same folders on a shared drive? It'd be nice to not have duplicate folders on the same machine.
-
By hardlinking the files between BTSync shares you immediately "sync" the file and save the storage space.
Yeah! You'd save the disk space and the transfer time. Less saturation for everyone! \o/
-
... this would require BTSync to maintain hashes of your entire filesystem (or at least a subset you choose). And in this case, you typically would want hardlinks, not symlinks. Symlinks only used for directories and pointing to other filesystems.
Well, I'm sure you'd know better than me what type of link to use
I'm thinking it wouldn't have to hash everything on the file system, just look through the hashes it already knows of from other sources before syncing the same thing again.
Let's say I have synced file X from person A. Then I add a directory from person B. If person B also shares file X (known to be identical by looking at hash), hardlink to file X from person A and pretend that it has been synced.
The reason I am proposing this is amongst other things that we're thinking of using BT Sync within the company I work for, and there are a lot of duplicate files floating around - duplicated between different projects and whatnot.
-
It would be nice to have an option that's like
"Regardless of source, do not sync stuff that is already present on the computer. Create a symlink instead." (i.e., If a file has a hash that matches a file that is already synced from another source, symlink to that file instead of downloading a duplicate. If the symlinked file moves or disappears, remove symlink and sync file).
Eliminating duplicates from multiple sources :-)
-
I wish the wishes that are in the pipeline were available on a Trello board :-)
[1.1.12] Read only share does not hash
in Sync General Discussion
Posted
Come to think of it, I don't think the "master" has been brought online since the update. Would that have something to do with it?