yottabit

Yep, saw the corruption, too ... figured if BT opened the file to read the language to which I was referring they would see the corruption and maybe fix that, too. :-) As for explanation of the wildcards, I don't know. I realize I'm an IT veteran, having started on computer with an Atari 65XE and then into MS-DOS 3.21 shortly thereafter, but rather than making that file huge with all of these explanations and examples, perhaps a link to a FAQ at BT would better, for those that really need more detailed instruction.

I was trying to keep my Outlook .PST file from synchronizing, since until btsync has true delta transfer capability for variable-length changes it just tries to transfer my files continually and never finishes (when Outlook is open). This .PST file is > 9 GB. To that end, I put a .SyncIgnore file in the subdirectory containing my .PST file, and added "*.pst" to the end of the file. It didn't seem to have any effect. btsync kept transferring the file, even after exiting and restarting the application. Then I put "*.pst" in the .SyncIgnore file at the root of the sync tree, where btsync had created the file on its own, and it worked. I interpret the language in the file as saying the .SyncIgnore file must be in the same subdirectory as the file I wish to ignore; however I know that isn't true because I've read some forums posts here about people ignoring nested subdirectories. From the file itself: So either the language in the file needs updated to make it clear that .SyncIgnore needs to be at the root of the sync tree (shared folder) only, or maybe btsync needs updated to honor the file in subdirectories, too? (This would be similar behavior to how .htaccess works in Apache.) Maybe change the language to something like: # Note that .SyncIgnore is only used from the top-level shared folder (root of the sync tree) ...Thanks! Excellent product!

You have Windows, MacOS, and Linux ... but no FreeBSD love? Would absolutely love you guys to death if you provided a binary for FreeBSD 8.3! And I say FreeBSD 8.3 specifically because that's what FreeNAS 8 is using. Running the binary from a startup script is just fine, and additional future features could include adapting for the FreeNAS plug-in system and allowing user/group permissions sync into various ZFS datasets. For example, say I have 5 users on the FreeNAS, each with their own dataset, it would be nice if btsync could keep the proper permissions for files transferred to each of those datasets (i.e., files into user1's dataset should chown to user1:user1). Right now I have a FreeNAS dataset mounted to a Linux VM, and btsync running on that Linux VM to a shared folder on the mountpoint. It works, but involves two systems and transferring all of the data twice (once to the Linux VM host, and then a second time to the FreeNAS mountpoint). btw, FreeNAS doesn't include the FreeBSD Linuxulator compatibility kernel module to directly load the Linux ELF binary. I also read elsewhere in the forums that folks were unsuccessful getting btsync to load on a full FreeBSD system due to lack of a specific call in the Linuxulator that btsync needs. Rumors are there's an alpha patch to FreeBSD 9 that enables that call. But again, FreeNAS's FreeBSD 8.3 doesn't include the Linuxulator kernel module, so no choice there but to have a FreeBSD-native binary available. Thanks guys! You rock!

I'm adding FreeBSD to the wishlist sticky. I also tried to get it to load on FreeNAS (FreeBSD 8.3) without luck, because the linux kernel module isn't available. Since this is a NAS distro, the source isn't there to compile from, either. I could probably get it in there manually but that's a lot of bother, especially with the restricted space on the OS disk (2 GB).