sagdusmir

This is wrong on so many levels… edit: GreatMarko missed one of your points: "You can always grab the latest update on the main page in the download section" is definitely not true. That's why there are dedicated download urls are published in the first post of this thread.

Full ack. Then btsync should stop creating .AppleDouble files in the first place.

I have btsync installed on some Macs and a NAS with HFS+ format. For me using btsync results in a mess of generated and removed (.SyncArchive) .AppleDouble files and unfinished syncs. I have not tried syncing files that I know of that depend on a resource fork. So far I tried btsync on camera raw files and mp3 files.

Don't mix up the meanings of resource fork and metadata/extended attributes. The mentioned ".DS_Store", ".fseventsd", and ".Spotlight-V100" files/folders and "extended attributes" and "metadata" are optional on only a nice to have for most users. Missing resource forks in contrast will effectively destroy most types of files on a Mac. On unsupported file systems you will eventually get ".AppleDouble" files to carry this information - but i guess this does not play nice with syncing on file level. resource fork ≠ metadata A sync tool that does not get along with resource forks should never ever overwrite/replace/move/touch a file with resource fork on a Mac. (IMHO) Instead it should quit with a warning and ask the user to exclude all types of files with a resource fork before doing anything in terms of syncing.

Yes.

After trying it for myself: Not cool. Suspended btsync and waiting for a fixed version.

I think the "beta" tag was rushed. From my experience the core functionality is far from being usable for most people. I am trying to sync 340GB payload in 40k files. I have 4 devices (latest version). I am the only one who actively edits files (one device runs crashplan on the same set of files). It does not work (yet). I do really want this to work for me so badly. It gives me a mess on all devices. The idea is great but i think most people using btsync in "beta" will loose data to some extent. I seems to work perfectly on fewer files and it does sync large files very well (maybe due to the fact that bigger files are usually used in a different way than smaller more "editable" files). Very nice proof of concept. This makes it an "alpha" from my point of view. Everyone must be aware that an unstable sync tool has the potential to trash all your synced data on all synced devices. The SyncArchive folder will not prevent this from happening.

I had iTunes Media in sync on two devices (depending on your directory structure you should exclude everything containing iTunes metadata). Then I added another device and some files and let it alone some days.... I got many files stuck in sync limbo and some moved to SyncArchive.... I did a manual check with ChronoSync (my goal was to replace ChronoSync with something "auto-magic") and have now turned off btsync for everything except the unimportant stuff.

My request would be: "option per share: do not create .AppleDouble files". Please. I have some music and some photos that i would like to sync. I don't mind their extended attributes/resource fork. Syncing 30k of photos (photo raw files - not some tiny jpegs) gives me 30k of useless .AppleDouble files that slow down the sync process and are prone to sync conflicts and end up in at least another 30k files in .SyncArchive (i don't even know if i would ever search in the SyncArchive for a special version of a resource fork for a synced file - this sounds pretty useless to me). These .AppleDouble files are then synced back to my hfs+ file system. Is there no way to re-unite the resource fork and the data fork?

I sync multiple devices running OS X and i get those .AppleDouble files everywhere although all devices are using HFS+ file systems. Is this supposed to happen?

OS X 10.7.5: 1.1.42 (and previous versions) fails to index all files in 2 of my 4 synced folders. The problematic folders have 110GB in ~9k and 230GB in ~36k files. btsync stopped indexing a newly added folder when i added a (new) 2nd one with many files.

OS X 10.7.5: 1.1.42 crashed three times when i tried to remove folders: Same steps for every crash: In folder view I selected the [ - ], "do not show again", confirmed delete -> btsync completely disappeared after a few seconds and the debug-log stalled. No a single debug line indicating what happened (even after starting btsync again).

Been there, done that. I second this request.

I have a strange behavior and don't know if this is an unusual usecase: I use 1.1.27 on a MacMini OS X 10.8.4 64bit, a MacBookPro OS X 10.8.4 64bit and on my Drobo 5N (ARM). I have set up multiple folders but at the moment only one folder has a sync problem. MacMini and Drobo have r/w access to a sync folder and are synced completely (as stated in the gui). The same folder should be synced (read only) to the MacBook Pro. The Problem: The sync stalls if i shut down the MacMini. If the MacMini is online then both (Mini + Drobo) upload data to the MacBook. The log file on the MacBook states a hash mismatch and that the Drobo (my home IP if I take my MacBook with me) is blocked because of this. Is this a known issue? Is there a problem with r/o sync? I tried removing/re-adding the folder from the Sync App on the MacBook but it always fails on the same files if my Mini is offline. Any Ideas? Should i send logs? All 3 devices (*sigh*)? Edit: I seems as it does not matter if there is a direct lan connection or not. I left the MacBook syncing (so i thought) all night and nothing gets transfered (I did not notice because of at least some "traffic" being displayed by the web gui produced by the occurring transmit/hash fail/blocking) Update: Same thing with 1.1.30. I assume the Drobo might be the cause for most of my issues. I will try to run btsync on another OS X machine instead (always on) in the next few days.