Add "no follow links" preference

[presto8]

I am not sure the history or design philosophy behind the current symlink behavior. However, for my application, I never want symlinks to be followed. In case it is helpful to others, I created this commit which implements a "no_follow_links" preference setting. For now, it is simply true or false. True means to never follow symlinks. False means to use the default symlink behavior (follow top-level links only I think). This could potentially be expanded to be a more generic preference, such as "follow_symlinks" with values of "never", "always", "top-level", etc.

Add a new preference "no_follow_links" which can be set in
.duplicacy/preferences to override the default symlink behavior.

If the preference is not set or is set to false, then the symlink
behavior is the same as before this commit.

If the preference is set to true, then symlinks are never followed. The
symlink is stored as a regular file in the backup.

[CLAassistant]

All committers have signed the CLA.

[TheBestPessimist]

I gotta say i have mixed feelings about what this PR wants to change. I think i was never in the situation where the root level symlink following caused problems.

[presto8]

Would you be able to share the situation where it is good to automatically follow symlinks? Most software I have encountered does not follow symlinks by default (e.g., rsync, duplicity, borg, ...).

Ultimately, this change is not essential, users can always use the filters to exclude any symlinks that they don't want backed up. In my case, I was surprised when my backup start being several terabytes instead of a few hundred MB due to a symlink being followed off filesystem, hence I thought I would submit the patch. If it is not useful or contrary to the intended design direction, please disregard :-)

[TheBestPessimist]

Following the top-level symlinks is a feature I always (ab)use by having a symlink repository instead of having multiple separate repositories.

[presto8]

Thanks for the link to the symlink repo. I just tried it out now, and I like it! Basically I set up a directory and link to all the directories that I want to from it. If this is the preferred method of operation, then perhaps it could be added to the Quickstart Guide? The reason I ran into trouble is I followed the guide and did it from my home directory, which has a lot of symlinks.

I still think it's a good idea to give the user extra control over symlinks; on the other hand, more features is more code to maintain and document. I will leave it in the maintainers capable hands to decide the fate of this one way or the other... in the meantime, I am enjoying duplicacy. As a long-time Crashplan and Borg user, I really enjoy Duplicacy!

[TheBestPessimist]

If this is the preferred method of operation

I don't think it is.
It's just a feature that I personally love and use, hence my reasoning about not inserting 1 more flag since it's (imo as a windows user who doesn't have symlinks everywhere) a rather minor use case.

[presto8]

Ah, interesting. Yes, I think Windows users use a lot fewer symlinks than Linux users do.

Is the concern over adding one more parameter to every method in the go code? Or one more line in the preferences file? If the later, since the default is to maintain the previous behavior if not present or set to false, then the parameter can just be left out completely...

For the go code, it was fairly invasive to add this one additional parameter. It may be a good idea to consider refactoring the code at some point to pass a single preferences object instead of individual ones...

[TheBestPessimist]

I guess we should see what gchen wants>.

[Ati59]

You should add your option in the app.Commands of the main() function.
Around line 1784, flags are defined.
It fixes a bug in your PR using the "set" command that results with this error :
interface conversion: interface {} is nil, not *main.TriBool

[callegar]

May I suggest that the rather peculiar behavior wrt symlinks is documented in the guide? What happens if the top level includes a symlink to some area outside of it to which the user has permission to read but not to write to? Will restore proceed gracefully when it cannot write to that space? Will a symlink to itself or to the repo root fill the storage or will the cycle be detected?