MicEdwards

Members
  • Posts

    19
  • Joined

  • Last visited

Posts posted by MicEdwards

  1. A great suggestion ... PLEASE make this happen ...

    ALSO ... is there any way we can have a checkbox in the app to get the most recent versions instead of just the most recent version you've approved for auto-update ... some of us *really* like the bleeding edge.

    Would it be possible to add a symlink on the server so that going to http://syncapp.bittorrent.com/latest takes us to the newest version? It would make it easier to update across platforms if there was a fixed URL.

    Just a suggestion :)

    Aaron

  2. There is a serious permissions problem in the Linux ARM version (and presumably the other Linux versions).

    I can see numerous other reports of the bug in these forums:

    http://forum.bittorr...hl__permissions

    http://forum.bittorr...hl__permissions

    http://forum.bittorr...mask#entry46668

    Here's an example:

    This is the tail end of the directory on the source machine:

    -rw-r--r-- 1 geoff staff 11837948 13 Dec 13:28 16 Sweet Georgie Fame.mp3

    drwxr-xr-x 18 geoff staff 612 13 Dec 13:28 .

    drwxr-xr-x 4 geoff staff 136 17 Dec 00:38 ..

    I have a read only sync setup to another machine, where these permissions are set:

    -rw-r--r-- 1 root root 11837948 Dec 13 05:28 16 Sweet Georgie Fame.mp3

    drwxr-xr-- 3 root root 4096 May 22 07:43 ..

    drwxr-xr-- 2 root root 4096 May 22 11:08 .

    Forget the bit where it is running as root ... (that's my ugly hackery) ... but look at the permissions on the directories!

    Yes ... the directories don't have the executable bit set.

    Of course, it would be best to respect the umask I have set as a default.

    All these directories become unusable to anyone but the owner (in this case root).

    Of course there are other things about permissions and ownership that could be improved, but just fixing the broken umask would be appropriate as a first step!

  3. I would cast my vote in favour of the .SyncID files and certainly against another breaking point like a sqlite database. I am particularly concerned about removable drives and I don't see another solution.

    I am also in favour of a .SyncTrash in each directory. it's a pain restoring from a parallel tree ...

    Would definitely love to see empty folders prune though!

  4. This is not really a question for just SyncApp, but for all applications.

    You can set (in the System Preferences, Network panel) the order of networks to use on each machine.

    The first connected interface will be used for all traffic (assuming they are on the same subnet).

    If you have two machines and they both have Ethernet and WiFi available (in that order), then they will communicate using Ethernet. If the Ethernet goes down, WiFi will be a backup, but only if the Ethernet is disconnected.

    If WiFi is listed as a higher priority interface (on both), traffic will use WiFi. If the two machines are configured differently, you may get asymmetric routing.

    This applies to all network applications.

    If the networks are on different subnets, all bets are off, although OSX will still use the highest priority available route.

  5. So, you linked two computers: one with empty folder another one with files in folder, nothing happens. Only new files that are added will be synchronized. Is that right?

    That's right. That's exactly what I saw. Empty computer was a fresh install of 1.0.67 on Linux arm. Other computer was OSX.

    I will try to reproduce over the weekend.

    We are going to revisit the way we configure Linux client in next version. This will be addressed too.

    Cool. This is a bit opaque right now

  6. Have updated to the latest version on Raspberry Pi (SyncApp_arm 1.0.67):

    1. When I start with a empty folder and link it to a folder being shared by other machines, I do not receive any of the content from the existing folder.

    Only content that is added after joining the share, or is updated (for example, renamed), will show up in my RasPi share.

    2. Is the option on the command line for the 'config' file path supposed to be the path to the '.sync' directory? I don't think the '.sync' directory should be written into /usr/local/bin where I have copied the binary.

    3. When a directory is deleted on a remote machine, it is being emptied, but not deleted on my RasPi.

    4. i like the longer secret, but is it enough?? ;-)

  7. Here's another bug which I've managed to tickle on the Linux_arm version:

    I am syncing a folder on a removable drive, but if the drive is not mounted, SyncApp empties the contents of that shared folder on the other hosts ... because the local folder (which does not exist unless the drive is mounted) is 'empty'.

    It seems that you should probably keep some settings for each share inside the share itself, so that the code will not try to sync a folder that is not mounted. Of course, you probably don't want to sync the settings themselves, but it would make sense for a share to be more self-contained.

    I have worked-around the problem for now by writing a wrapper which ensures the SyncApp daemon is not started unless the folder is present.

    Thanks!

  8. Is this an appropriate place to discuss bugs in the alpha implementation?

    What about general concerns regarding security?

    For example, is it really the case that when using BitTorrent Sync, access to a shared (synced) directory is really only protected by a 12 character mixed-case alphanumeric key?

    THERE IS SO MUCH POTENTIAL IN THIS STUFF, BE CAREFUL YOU DON"T GET BURNED BY SHIPPING A HOLE LIKE THAT!

    Thanks,

    Mic