bradmurray
-
Posts
15 -
Joined
-
Last visited
Posts posted by bradmurray
-
-
Looks like 1.1.82 is being served now.
Why is there no update to this thread? Also, http://syncapp.bittorrent.com/1.1.82/ does not exist and there is nothing reported when trying to update from within the apps.
-
On the Android and iPhone clients it would be nice to be able to set the "use cellular data" option at the share level. I have a share that contains large video files that I don't want chewing my bandwidth, but I'd like to keep everything else up-to-date all of the time.
-
I can't wait until 10 years from now and I show off my geek credit by giving out a read-only password to my sync folder that begins with a 4. I'll send it from my ICQ acct 101294.
-
According to the install warning on 1.1.33 this is now part of the app. I haven't restarted my phone to test it, but it is in the permissions now.
-
Surely the first letter does not control the secret's function.
It doesn't control it, but it does designate the type of key. Changing A to B will not change the function as it will invalidate the rest of the key. You can see this by comparing the full key for a folder you already have to the read-only key that it gives you if you ask for it. It's just a human-readable thing. They do the same thing with credit cards. Visas always start with 4 (MC with 5, AmEx 3 Discover 6). Changing the first number doesn't change the card type. It invalidates the number because there is a built-in checksum.
-
Right now files larger that 2GB seem to be broken on Android. The problem is that it keeps trying to sync the file unsuccessfully. If you could set it to just ignore files that size then it would be OK until you get the sizes supported.
-
I'd vote for a more rsync like behavior of the temp file while syncing, i.e for file file.ext, make the file.ext!sync a copy, and move to the original file (i.e overwriting/replacing it). This would be a huge benefit when syncing webpage content, as there'll be no 404 while a sync of a file is in progress.
Along this line (requested by somebody else) would be the option to have this copy temp-file in a separate folder and not alongside the file, in order not to expose partially synced files.
I do see the purpose of the current behavior for many scenarios though (i.e preventing someone from concurrently modifying the file, saving disk space as you don't end up using twice the space during transfer, etc.), so it would be very nice if this could be configurable on a per-folder basis.
Second on this. I have a directory that is running on BTSync between two computers, but it is also being mirror to an online backup company. The mirroring program is always trying to mirror these !.sync files. If I had a temp folder on the same physical volume where all of the !.sync files could go while they are in progress it would make it a lot cleaner with this and many other apps. I have planned on using BTSync to publish web code, but this would cause a problem there as well. The temp directory should name files as the full destination path with the slashes converted to ~ or something like that so if it gets stuck you know where the file is supposed to go.
-
It seems that the android app chokes on files larger than 2GB. Is there a plan to fix this or can we at least get it to ignore 2GB files for the time being? As it is any file larger than 2GB seems to just become a *.!sync file and sit in the processing queue without finishing.
-
If we had decent logging and a record of every device that connected and disconnected from a share we would at least be able to monitor what is going on and maybe even put decent alerts on any time a new device connects. Heck, you could have an option to require a manual acceptance of a new device into a folder by at least one of the existing participants.
-
To add insult to injury after I left my house this file kept trying to sync and I immediately went over 2GB used for the day all on BTSync. I don't even have data over cellular turned on for the app and it did it anyway.
-
I have a 3.5GB file that I am trying to sync from Windows 7 (1.1.27) to Android (1.1.7 on a Galaxy S4 going to the external SD card) and it has been running for a few hours. The Windows client says that it is running mostly over 3MB/s so it should have finished in about 15 minutes. On the phone the KB/s status keeps popping up and disappearing so it looks like nothing is happening there, but Windows continues to show progress. The folder that is syncing is very small and only has one other file in it that is a few hundred MB.
-
I just ran into this problem in Windows/OSX as well. I am syncing a file where the full path is 250 chars. If you add on the .!sync extension for the temp file you get to the magic 256 length and the file just syncs over and over again. It is only a 1MB file. I tried closing sync and manually syncing the file in both locations and then starting up, but it seems to puke on that length of file name. When I shorten the name everything works fine.
-
I don't see a problem with multiple clients running on the same machine as long as they are on different ports and sharing different directories. If you write the PID in the shared directory on launch you can keep a second instance from trying to sync the same folder. The only catch would be one session syncing /mnt/a/ and another trying to sync /mnt/a/b/ to it.
-
I synced a directory of about 20GB (10K files) and there were two files that showed that they were each doing about 1.2MB/s for a while, but the files were only 8MB and 3MB in size. I let it run overnight figuring it was a display bug and the syncing was going on in the background even though each computer already had a mirror of the data. When I woke up the same two files were still going so I paused it. On the Windows side I had dupes of the files. One had the double quote character and the other had a which looks like a bullet in explorer. On the Mac there was just one of each file with the double quote. I paused syncing and renamed them to 'inch' instead of the character and all is well. I have seen this problem with other syncing products in the past, but just thought I'd raise it.
did not pick any blocks. blocking peer temporarily?
in Sync General Discussion
Posted
I have this problem all of the time. For example if I modify a bunch of metadata in MP3 files and they have to be re-synced I will get this on a bunch of random ones. The only solution I have found is to stop both clients, manually copy the file, delete the *.SyncPart and *.!sync files in the destination folder, and restart syncing. I usually pause the client on my macbook before I do the batch mods and resume it when I'm done so I don't think it is an issue with it trying to pick open files.