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] MD[F28B]: Failed to apply folder changes [2015-08-19 00:45:57] MD[F28B]: Loading notifications [2015-08-19 00:45:57] MD[F28B]: [load notifications] Aborted: sync manager is not initialized and in the journal getting longer and longer growing lists of `processing file renaming` where the symlinced folder name and its parent are repeated over and over in a growing manner. Please make the symbolic link handling code aware of this ASAP (ready to test alpha builds on this). Or if the code is just following the link automatically and unaware of this behavior on windows, please make it aware of it. Check dir if it is a symlink and then check if linked folder is also a symlink and only sync the real target, some while loop should do the trick, possibly with a break condition after 100 links max (if thats not too high, cant think of a good reason of so many links following each other, other than the obvious circular dependency which should be avoided by the break)
  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 appear on machine2, but at that point, it disappears from machine1! Then after a few more minutes, it travels back to machine1 and disappears from machine2. This back-and-forth continues indefinitely. This must be a bug. I see no other reason why the two symlinks should be handled differently simply because one of the subdirectories starts with a "." I hadn't noticed this issue before upgrading to 2.0, but it could have been present before. I'm using BitTorrent Sync only on Linux.
  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 the point - if I want to use Sync for the purpose of backup, then I would like it to sync Windows symlinks too. For debugging/testing - symlinks can be created from Windows command line with admin privileges as follows (eg. for directories): mklink /D C:\target D:\sourceDir Therefore in Linux the symlink should also point to D:\sourceDir, even though in linux that's an invalid path. This should work also the other way around - at the moment linux symlinks don't get copied to Windows at all. The only problem I see with (re)creating symlinks in Windows is it requires elevated privileges, but I am sure for users who want to use that feature it won't be a problem (syncing of those could be delayed until the user confirmins the action). Thanks for a great product! All the best
  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.