rdebath

Members
  • Posts

    289
  • Joined

  • Last visited

  • Days Won

    6

Profile Information

  • Gender
    Not Telling

rdebath's Achievements

Advanced Member

Advanced Member (3/3)

  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 pretty good, but it is a scheduled thing not an update on changes and must have exactly the same version of the application at both ends of a pairing. It used to have a problem with large files; but I think that's been solved by having an option to use an external file transfer program (rsync). (Note: Files are transferred between pairs or nodes, but there can be lots of pairs) Sparkleshare, yup, what he said. Oh and the FSF one is very, very, new so developers will be playing with pieces but mostly waiting to see how BTSync turns out.
  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 before a traditional file transfer has moved a single byte to a peer! That's the whole reason that Bittorrent is popular with anyone. But it's really popular with the pirate crowd because in low performance modes it costs nothing beyond the internet connection. Higher performance modes can use a "cloud server" to speed up downloads for peers that connect to the swarm late, but they (pirates) don't want to pay for that, still, even 'low performance' is very very quick compared to FTP. But up to now, Bittorrent has been a pain to setup (torrent files, http servers for trackers, DHT networks getting details) and insecure (no authentication on peers what so ever, encryption, if present, only obscures data from eavesdroppers). BTSync makes it very, very, easy to setup and secure, all you need is a directory and a 'secret'... Done. And before anyone asks, yes, it's normal for a company firewall to block the traffic by default and yes it's easy to allow BTSync.
  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 differently to those from other networks. The 0.0.0.0 is the correct IP address to bind the webui to in most cases. Generally, you only change it if you want to restrict where the webui is accessible from. The 0.0.0.0 address means no restrictions and BTSync will accept a connection from anywhere. PS: Some NAT boxes require a reboot even more often than Windows !!
  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 characters to UTF-8 for transmission. I suspect it would be rather complex to add an iconv conversion in the filesystem interface of the Linux client because it would be really difficult to say what should happen when CJK is involved at one end or the other. As for the other clients, there would probably have to be some complex choices as to the availability of the iconv library and data files (which are NOT insignificant) and a large number of new failure modes for very little gain. All in all it would be a lot better if you switched to Unicode with the rest of the world and used "luit" for those applications that simply can't be converted at the moment. But, don't forget to add this to the Wishlist thread.
  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.