Search the Community

It would be nice if btsync would be able to copy the symbolic and hardlinks as they are, and not just as a normal file as it does now. If the source and the target of the links are in same share, then create the same link structure on all synced computers (or at least on desktop OS). If not, then do as now, sync as a normal file.

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)