
Hello. I try to use BackInTime 1.4.1-1 for synchronizing files between two machines. Some synchronized files/folders located in different places (for example on other drive mounted in /media/user/...). Therefore i made symlinks to them and added to BackInTime include list. Also I enabled 'Copy links' in 'Expert options'. Taking snapshot works well, but restoring not quite - program replaces symlinks with restored files. How to tell it to replace real file on which symlink points to? Logfile: https://pastebin.com/uSzpX9Hi

Hi Artem, if you look inside the backup folder: do the relevant files exist as symlinks there? If yes, then the problem is in the restore process. If not, then it's the backup process that acts different from your expectations. Feel free to open an Issue on Github, so we can track this unexpected beahvior as a potential bug. Cheers Michael On 05.07.2024 12:58, Artem wrote:

Artem, It sounds like you are wanting to backup files within symlinked directories and then restore those into existing symlinked directories. I think you could use "--copy-dirlinks --keep-dirlinks" in the extra rsync options at the bottom of Expert Options. The first will follow the symlinks on the source side, and the second will respect existing directory symlinks on the target side. Beware that, depending on the scope of what you're syncing, there might be other symlinks that might be followed in a way you wouldn't want. You could run `find <some-directory>/ -type l -xtype d -ls` to look for what other directory symlinks are in your include folders. The snapshot would only have regular directories and no record of which ones were symlinks, so if the symlink doesn't already exist where it's being restored, a regular directory would be created for it instead. If using "Restore to ..." from the Restore menu could do what you need, that might be simpler and safer. Derek On Thursday, July 11th, 2024 at 12:46 PM, Michael Büker <foss@michael-bueker.de> wrote:

Hi Artem, if you look inside the backup folder: do the relevant files exist as symlinks there? If yes, then the problem is in the restore process. If not, then it's the backup process that acts different from your expectations. Feel free to open an Issue on Github, so we can track this unexpected beahvior as a potential bug. Cheers Michael On 05.07.2024 12:58, Artem wrote:

Artem, It sounds like you are wanting to backup files within symlinked directories and then restore those into existing symlinked directories. I think you could use "--copy-dirlinks --keep-dirlinks" in the extra rsync options at the bottom of Expert Options. The first will follow the symlinks on the source side, and the second will respect existing directory symlinks on the target side. Beware that, depending on the scope of what you're syncing, there might be other symlinks that might be followed in a way you wouldn't want. You could run `find <some-directory>/ -type l -xtype d -ls` to look for what other directory symlinks are in your include folders. The snapshot would only have regular directories and no record of which ones were symlinks, so if the symlink doesn't already exist where it's being restored, a regular directory would be created for it instead. If using "Restore to ..." from the Restore menu could do what you need, that might be simpler and safer. Derek On Thursday, July 11th, 2024 at 12:46 PM, Michael Büker <foss@michael-bueker.de> wrote:
participants (3)
-
Artem
-
Derek
-
Michael Büker