Brian Buchanan

Members
  • Posts

    12
  • Joined

  • Last visited

  • Days Won

    1

Posts 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 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. Solved this.  the QNAP BitTorrent package modifies webui.zip then does a chatter +ia to webui.zip which prevents that file from getting updated.  I deleted webui.zip and restarted btsync and the new one was written.  I removed the chattr line from the qnap btsync.sh 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.

     

    PBlD0ra.png

     

    *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 webui.zip 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.

  3. 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 http://forum.bittorrent.com/topic/29255-btsync-error-check-too-many-open-files/

     

    Tried http://syncapp.bittorrent.com/1.3.77/ and the number of open files no longer grows out of control, 7 or 14 is all I've seen.

  4. 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).

  5. 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)

  6. I got it running on my DroboFS following this guide:

    http://www.droboport...1-0-132/drobofs

    1. 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.
    2. Downloaded btsync.tgz and copied it into the DroboApps drive
    3. Used Drobo Dashboard to restart the DroboFS
    4. Browsed to http://{drobofsipaddress}:8888/
    5. Added a folder, pasted the Secret and it started working.

  7. 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.

  8. 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?