Brian Buchanan

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Brian Buchanan

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