• Content Count

  • Joined

  • Last visited

  • Days Won


About rdebath

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  1. You're converting the hex to base32 'incorrectly'. Simply if you're taking the bits from the hex and reencoding them as base32 it should be 4/5 the size of the hex. It looks like you're taking the hex as ASCII bytes and encoding that instead. 'Correctly' .. Start with the string "cats" The SHA1 in hex is "8ebf601f8b808c32b8d2fb570c2e0fbdbb388add" The SHA1 in base32 is "R27WAH4LQCGDFOGS7NLQYLQPXW5TRCW5" Put that into BTSync and get ... cats. NB: http://www.debath.co.uk/MakeAKey.htm ALL in javascript.
  2. Okay, peerdrive is a distributed filesystem, your data is stored in a peerdrive volume not on the filesystem. This makes it very difficult to port. It's use of the 'Dokan' library is probably an issue as that 'WindowsFUSE' library isn't being updated and updates were apparently stopped because of unsolvable compatibility issues. Powerfolder appears to be bound to a server in some rather complex way that allows them to limit what's transferred. They also claim only the "CORE" is open source, whatever that means. (NB: I don't like java either, it tends to make things awkward to run) Unison is pr
  3. I raised the issue of the birthday problem when the default keys were 128 bits; with that there is a very borderline chance that someone may be able to break something so that there is just barely a chance of a birthday attack within the foreseeable future. The minimum key was extended to 160 bits and fixed this.
  4. Love the idea, especially if any of them has played World of Warcraft. The simple fact is that Bittorrent is just a file transfer protocol like FTP or HTTP (BTP perhaps ) and is used in EXACTLY the same way by exactly the same people. Nothing has been done with Bittorrent that wasn't done with both ftp and http first. The difference is that it's the fastest and cheapest one in existence. If working perfectly, it will finish transferring the file to all peers at the same moment that an FTP upload to a web host completes. So not only is it faster, but in the simple case Bittorrent has finished
  5. ignasigarcia, Some likely possibilities, You've not correctly configured the port forwarding on your NAT box, it needs to redirect external TCP port 8887 to port 8887 on your internal machine. ("DMZ mode" can be used for testing, but that mode also disables all the firewall like properties of your NAT router) You have a share currently defined in the config file; for some reason BTSync doesn't start the webui if there are any shares defined directly in the config file. There is another firewall messing with you, for example, "windows firewall" will treat connections from the local network diff
  6. You can use BTSync to sync the container if it's unmounted. BYSync will choose the one with the most recent timestamp and should happily use a block aligned partial transfer. (Not rsync, but good enough in this case) However, in it's current state, if the container is mounted it's likely that BTSync will consider it's read error to be a deletion of the container and remove the container on the remote system, hence, triggering a full transfer when it can again read the file. So I would not recommend you use BTSync without carefully backing up all files within the share.
  7. I would guess that there was some sort of permission, full disk or disk error on the 'receiving' system. BTSync still deals very poorly with that sort of thing treating it's failure to make a change as an active user reversal of that change; ie if it can't create a file it pretends a user deleted the file. Another nasty effect of this is that if one BTSync can't create a file and another can't delete a file they continually throw deletes and recreates back and forth. Obviously, this is a very poor choice. A better one would be to treat the file as locally ignored.
  8. Truecrypt has the problem that it's a container based system and BTSync won't be able to sync the container when it's open. This will mean that it will have a serious problem if the container is changed on two machines; one or the other will have to win it can't sync at the file level. Another issue will be that you can't reasonably use SynchTrash (now SynchArchive) because it'll only have whole copies of the container, not small files.
  9. NT based Windows uses Unicode (UTF-16 to be exact nowadays) and always has done (Win95/98 can use unicode but don't by default). It converts the 'OEM' and 'ANSI' character sets using somewhat non-standard tables. The US and Western Europe windows ANSI character set is CP1252 which is an extension (or rather several extensions) of ISO-8859-1. The character set ISO-8859-15 does NOT contain all the graphic characters in the CP1252 set (nor does ISO-8859-1) As I understand it, at the moment the Linux client does nothing with character sets, it's the windows client that converts it's UTF-16 charact
  10. This magic is already available in the package ecryptfs-utils. This package allows a user to have a directory (or their entire home directory) encrypted and mounted (fuse filesystem) at logon. None of the files on the filesystem will be available if the user isn't logged in ... if the entire home is encrypted this, unfortunately, will also include the ".ssh" directory with it's "authorized_keys" file.
  11. I suspect you'll have to delete the entire ".sync" directory and re-add your shares. But by all means see if just deleting the file will work first.
  12. Local .SyncIgnore files would be easy to understand. All it means is that a file would be sync'd to ".SyncNowhere/The/file/path.txt" rather than "The/file/path.txt". Any real file at "The/file/path.txt" would be completely hidden from BTSync. The optimisation would be that anything that the peer would download into ".SyncNowhere" wouldn't be sync'd until tomorrow ... forever. With local ignore files like that you'd only have to "Ignore" the files on the peer they were created OR the peer that doesn't want them.
  13. Following *.LNK files is VERY unlikely to happen. For now, at least, BTSync will follow real symlinks on Windows though.
  14. In the wish list; currently the only way to do well it is to use encfs.
  15. BTSync assumes your Linux machine is using UTF-8 for it's system character set (locale de_DE.UTF-8 or similar). You really should switch to it you know, otherwise how can you represent a file with a "☺" or a "☢" in the name. Modern terminal emulators can all do UTF-8. (By definition ) If yours isn't modern I, of course, would recommend PuTTY or Pterm.