Brian Buchanan

  • Posts

  • Joined

  • Last visited

  • Days Won


Brian Buchanan's Achievements


Member (2/3)

  1. On my QNAP TS-269L with firmware 4.1.0 Build 20140612, after removing and reinstalling the BitTorrent Sync 1.3.106 app I'm prompted to set a password for admin. Pretty standard stuff. If I use a simple password such as "1234" everything works just fine. But if, after deleting and reinstalling the app, I use a long complex password such as "07hQ8DQ#W7vdjD%e7Z1U64ty" I can't login! I determined that "#" was an invalid character although that wasn't flagged when I pasted it in and confirmed it. Can you please accept any number of upper and lower case letters, numbers, symbols and special characters in the GUI password? And if you can't, can you please put a note as to which characters are, and what length is, legal? Thanks.
  2. Having the same problem here with Ubuntu 12.04.4 LTS and btsync 1.3.105. The credentials used are those found in /etc/btsync/{instance}.conf and not $storage_path/settings.dat After changing the username/password in the gui the new username can be found in settings.dat until the service is restarted.
  3. Solved this. the QNAP BitTorrent package modifies then does a chatter +ia to which prevents that file from getting updated. I deleted and restarted btsync and the new one was written. I removed the chattr line from the qnap launch script. ---- I'm trying to add a folder on Linux but I can't get past the "Destination folder is not empty. Add anyway?" message. This succeeded on the ARM version of 1.3.105, I never got the warning, but on my QNAP i386 version of 1.3.105 this warning came up and I can't get past it. Another side-effect is that the message persists if I cancel the dialog and go back into add a folder. *Edit: The ARM version on my DroboFS gives a pop-up confirmation that says "This will share the contents of "..." with everyone who has the key." and I can click Ok and the folder is added. The i386 version on my QNAP doesn't give me the pop-up. I got it figured out. On the Qnap I had to delete the file in the .sync directory. When I did the upgrade to 1.3.105 All I did was replace the btsync file, I didn't think I had to touch anything else. Sorry for the trouble.
  4. Thanks. Had this problem, reverted to 1.3.77 and it's working well again.
  5. I seem to be having this problem with btsync 1.3.80 (32-bit) on a QNAP TS-469 with when receiving a lot of files from peers. It runs for a while and then "Check: Too many open files" starts appearing in the log and in the GUI the "Size" says "Don't have permissions to write to the selected folder." The lsof command does grow as btsync is running (substituting my folder name in for btsync-da) and shows 1365-1477 files usually. When it stops. Stopping and restarting btsync gets it going again for about 2 minutes (lots of small files). *Edit: From Tried and the number of open files no longer grows out of control, 7 or 14 is all I've seen.
  6. Sorry, yes I meant renaming a directory within a BTSync controlled folder. Nomenclature can be difficult. I'm running Windows 7 64-bit and have a BTSync Folder on an NTFS partition. In that folder I have a directory called Pictures with a pile of .JPG files. I created a new sub-directory inside "Pictures" moved some of the JPG files into it. On my other BTSync device (also Windows 7 64-bit NTFS filesystem) I saw the History say that several files were added by the first device, four were processed as a rename and a bunch removed. I have 139-GB & 34,933 files in my BTSync folder. Maybe it didn't notice the rename except for the four? Edit: I just tried again. Moved 30 files in "Pictures" into a subdirectory within pictures. BTSync recorded 30 adds and 30 removes, however the other device recorded the first 15 as "added" and last 15 were "renamed" (the events were recorded in sorted order by filename).
  7. Under Windows 7 64-bit on an NTFS filesystem, I moved about a dozen pictures into a subfolder and they were deleted and recopied on the (windows 7 64-bit NTFS filesystem) partners. It doesn't appear too keep track of files as independent objects. This might be different on Linux with a filesystem that uses iNodes (ext2, ext3, ext4, etc.), as those would remain the same regardless of the folder(s) that the iNode was in. (my knowledge of filesystems is limited)
  8. I got it running on my DroboFS following this guide: http://www.droboport...1-0-132/drobofs Browse the DroboFS with explorer (typed \\{drobofs ip address} ) and mapped a network drive to the DroboApps shared. The DroboApps Share isn't visible through Drobo dashboard. Downloaded btsync.tgz and copied it into the DroboApps drive Used Drobo Dashboard to restart the DroboFS Browsed to http://{drobofsipaddress}:8888/ Added a folder, pasted the Secret and it started working.
  9. If I rename a folder, do the peers delete the old one and then resync the contents?
  10. Each share has two keys right? RW and RO? So those probability numbers should be halved? This scheme is very interesting as it treats legitimate and illegitimate users the same. The issue is the possibility of legitimate users colliding. With a username & password legitimate users will never collide as they use their username, and so illegitimate users only have to guess the users password.
  11. Thanks. I'd hate to be the first person that's victim of a collision. Can you find how many secrets are needed for a 1% chance of collision and a 0.1% chance? (rather than 50%) (Sorry I couldn't figure it out myself, I just don't understand the math) Edit: I just saw the Probability table (and reading the Birthday Attack) for 128-bit key and the 1% probability for 128-bit is 1.6×1076 which is huge and the secret is 168-bit? and the keyspace would be 240 times bigger?
  12. Can someone apply the Birthday Problem to the numbers in this keyspace? I'd like to know how many secrets are needed before there's a greater than 0 possibility of a collision?