Dropbox and smartsync

Hello,
Dropbox has a feature called SmartSync, meaning that instead of having a file stored locally you have a placeholder and when you try to access that file it gets downloaded from dropbox server to the computer.
Now when duplicacy tries to backup the file the dropbox client downloads the file.
In the past (I think before 2.3) it didn’t but the backup gave warning (which is fine for me)

WARN LIST_LINK Failed to read the symlink XXXX: Unhandled reparse point type 44

I don’t want duplicacy triggering the download of those files, I don’t have enough space on my hard disk for that.
Did something change dulicacy side or Dropbox?
Anyone with a suggestion to avoid this?
Thanks

I believe there hasn’t been a change in Duplicacy that can cause that. However, 2.3.0 was built with go 1.12 and I don’t know if there was a change in the handling of reparse points in go. Can you run a test with Duplicacy 2.2.3 to confirm?

Could any of theese be related @gchen ?

I can confirm.
Duplicacy 2.3 triggers access of file so that the file is downloaded
Duplicacy 2.2.3 gives warning but doesn’t trigger the file

I’ve checked dropbox forums and there’s a lot of people complaining about this, using macos time-machine and other backup apps. They say it’s normal behavior because the backup app needs to access the file. It’s quite surprising that duplicacy 2.2.3 can handle it quite well.
As a non programmer it seems to me that duplicacy 2.2.3 (older go)checks the validity of the link somehow and gives warning if there’s nothing on the other hand. Duplicacy 2.3.0 access the file, triggers the download, wait dropbox to finish syncing the file and then does the backup. This also explains why it takes ages to do the backup of the dropbox folder with duplicacy 2.3.0.

As a side note: the download of the file is triggered only if duplicacy doesn’t know the file. If I do the backup of the file, set the file to online only using smart sync of dropbox and run the backup again the download is not triggered

1 Like

This does look like not only correct but highly desirable behavior then. Otherwise when backing up on-demand folders like that how can you rely on your backup if you can’t be sure what files are there or it ever had a complete set of your data to begin with?

I don’t know about windows but MacOS iCloud Files manage the local cache automatically based on available local space — so if Duplicacy indeed forced fetch for the purposes of a backup — that’s awesome. If we run out of space the system will take care about the purging the cache.

In fact this is the feature I always wanted but did not think was possible until now. @gchen, please don’t break it; or at least make it configurable if you do.

With respect to reparse points for on-demand files Duplicacy should either skip entire tree altogether, as it used to do before, or do the right thing and force fetch, as it seemingly does it now. Backing up only some files that just happened to be local is counterintuitive, unreliable, and will lead to data loss and user frustration.

Why not specify a filter to exclude the Dropbox directory if you don’t want it backed up?

1 Like

Instead what you are saying will probably work only on macos, all other syncing client I know do not remove local files from your hard disk when you run out of space. Files do not happen to be local on windows and linux. In my case I choose those files and directory to be online only, I keep the things I need on my hard disk and back them up.