MicEdwards

One solution would be to use Hazel to add the files, making sure you deliberately exclude the .sync! files.

Thanks again for Sync ... it's an amazing gift to the world.

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.

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!

Can I just download them again from the original location, as I did with .95? UPDATE: Apparently not, as the version at the original download URL is still .95 ...

When I ask the OSX version to 'Check Now' for updates ... NOTHING ... I am on 1.0.95 Back for another manual download and install.

Wow ... very unusual behaviour ... I would triple-check everything again to make sure ... Maybe run the command "netstat -rn" in the Terminal and paste the output in a message here. That should help us to work it out ...

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!

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.

Great ... looking forward to it!

Just wanted to let you know that I have SyncApp_arm running on a Raspberry Pi on the Raspbian Linux distribution. I know it's not strictly a NAS, but I am using it as one ...

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. Cool. This is a bit opaque right now

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?? ;-)

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!

Also ... if the file is encrypted, it will not matter if you have diff, because encryption often (usually?) modifies the whole file. So, yes, rsync and Dropbox might do this by chunking for normal binary or text files, but for encrypted ones it doesn't really help.