Search the Community

Showing results for tags 'symlink'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Resilio Sync
    • Sync General Discussion
    • Sync Troubleshooting
    • Sync for NAS (Network Attached Storage)
    • Sync Stories
    • Developers
    • Feature Requests

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 8 results

  1. I'm syncing two directories between my Linux laptop and my QNAP NAS station. There are some symlinks, which I would like to have synchronized as well, without its referenced content. Yet the symlinks do not get synchronised at all (neither dereference nor following the link).
  2. Hi, it seems that BitTorrent Sync can not handle a symbolic link that does point to another symbolic link which then points to a existing directory. I don't know what the specification of symlinks is on Windows, but it is working. (Just found that out by using `npm link` to symlink a node_module to a local folder where I have a modified version of the publicly available module). I have not tried a test case if this is the real cause of the hang of btsync (using 100% of cpu and only printing `sync manager not started` or similar lines in the debug enabled sync.log: [2015-08-19 00:45:57]
  3. On machine1, within my /home/user/BTsync folder, I create a folder called "symlink_test". I create another folder called ".symlink_test" (it starts with a dot, i.e., a hidden folder). Within symlink_test, I make a symlink to a file in the home directory (ln -s /home/user/somefile.txt .). Within .symlink_test, I make the same symlink. In symlink_test, the symlink gets handled normally. It is copied as is from machine1 to machine2, so machine2 now has an identical symlink that points to /home/user/somefile.txt In .symlink_test, it does not get copied to machine2. After a few minutes, it does
  4. if a put a soft link folder in a BT Sync folder it doesn’t start syncing contents of that link. do you have any plans implementing this feature?
  5. Suggest using lstat() in linux puhleeeeeeeeeeez. I notice this where a directory contained large number of symlinks to remote nfs mounts... :-) stating each file took many seconds...
  6. Hi all, As I understand, Sync now synchronizes symlinks opaquely between Linux systems, which is great. But this feature works differently in Windows. Windows symlinks are followed and their contents are synchronized instead. I was wondering whether this is a bug? I have to point out that Junction Points / Mount Points in Windows are different to Symbolic Links. I would presume Symbolic Links would get synchronized across platforms (not the contents), so that in Linux I would also get a Windows link recreated. Of course it would probably not resolve, as it's a different device, but that's not
  7. I'd like to be able to symlink content into a shared folder. There are times when I'd like to consolidate items from the various sources into one destination on my backup/secondary. For example I don't want to sync all of my iTunes Media but I'd like to pick and choose items that aren't available from the cloud into a common shared folder. Perhaps it's safe to share each of those folders but the overhead of setting them up is greater... alternatively it may be easier to share a common ancestor folder but that may include gigabytes of files that I don't care to backup.
  8. I have a folder that has a number of real files and a good amount of symlinks that point to other drives. I want SyncApp to sync the real files around, but ignore the symlinks completely (as in not to sync the symlink or the file that the symlink refers to). Currently SyncApp copies the symlink as-is so on the remote devices I've got a bunch of links with broken paths. Since it seems like .SyncIgnore pays attention only to the file extension and not filetype I'm wondering if this is even possible. I'm running OS X 10.7 & 10.8 on all of my SyncApp-enabled machines, if that matters.