Bad behaviour with symlinks

[tkhyn]

Original report by Anonymous.

---

Context

Starting from two (already synced) folders:

Source dir: source/{1, 2, 3}
Target dir: target/{1, 2, 3}

Actual behaviour

If later we change source/3 to become a symlink (with the same name), we get this error:

Updating file target/3
[Errno 17] File exists: 'source/3' -> 'target/3'

This happens even with option purge set to True.

What I'd expect

I would expect either:

• to be notified that a symlink wants to overwrite a real file, a manual intervention is required (when purge=False ? maybe a custom option would be better)
• the real file is overwritten, the user is just logged that this happened (when purge=True ?) <-- in my opinion this is the best solution

[tkhyn]

Original comment by Anonymous.

---

For comparison, rsync always overwrites real files with symlinks silently, both with and without the option --delete.

[tkhyn]

Hi,

Sorry Andrea, I have very little time at the moment to dedicate myself to improving a tool that I'm not really using anymore. Reliably detecting symlinks cross-platform does not seem to be that easy and I have no time to try and add symlink support to dirsync. It will take at least a day including testing / debugging and I don't really have a spare day to do that at the moment. There are quite a lot of cases to consider if one wants things to be done properly (symlink targets can be files, directories, internal or external with respect to the root directory, etc.).

As you've already had a look at the source code, you've probably seen its structure is not very complicated so if you're keen to add some tests and the code, I'd happily accept PRs for this particular feature or any other.

I'll leave that open anyway, as it's a valid issue that should be addressed at some point.

[tkhyn]

Original comment by Anonymous.

---

No problem Thomas. I too noticed that it's trickier than it seems. If I can come up with something I'll make a pull request