Tracker won't copy symlinks

[humdinger]

This is hrev47801.

When copying folders around, I get this alert when Tracker happens on a symlink:

Error copying file "libWebKit.so":
    No Error (14)
Would you like to continue? [Cancel] [OK]

Choosing [OK], the file then isn't copied. If the file the link points to is among those that are copied, the link could then point to the copied file. Maybe that alert could be changed to giving the user the choice to

a) point the link to the copied file (if the target is part of the copy job)
b) keep the link pointed to the original target,
c) let the user choose the new target with a file panel d) continue without copying (the current behaviour.

I guess a) would be the default behaviour.

I'm not sure if this a bug, if Tracker always behaved like this or if it's an enhancement.

[ttcoder]

Ran into this last week too, though that was with symlinks (humdinger you do mean hardlinks, e.g. from the Linux ext2fs file system or similar right ? not BFS symlinks ?). If a symbolic link points to a non-existent file, I get the above requester with a red "!" mark.

My use case was copying the whole /boot partition of an old (pre PM) Haiku install from a failing HDD (with the infamous "click of death") to a fresh new HDD.. On a typical Haiku partition there were lots of symlinks, some of which might appear to be "broken" when seen from another partition, and so it was kinda painful to hit enter..enter..enter again and again to go through the whole thing :-) .. A "copy all" or "ignore all" (to acknowledge once and for all) would have been useful, true that.

[humdinger]

Actually I meant "hard" links as in the context of the "ln" help:
"Create hard links by default, symbolic links with --symbolic."

That is, links with an absolute path to the target, not a relative (symbolic) link.
But I now see that it's the same error when copying any kind of link..
(BTW, Tracker creates absolute/hard links by default, but you can create a relative/symlink by holding SHIFT while RMB-drag&drop.)

[humdinger]

My use of "hard link" was a bit confusing (and so is ln's...). Changed the ticket to "symlink" in general, because it turns out any Haiku supported links are effected.

[anevilyak]

This is most likely a more recent regression, this definitely used to work.

[waddlesplash]

If anyone has the time to binary-search for the rev that this broke on, that would be great. The last (major) changes to Tracker happened in hrev47664, no sense starting later than that.

[humdinger]

Just binary searched: works with hrev47659 doesn't with hrev47665
That makes mega commit hrev47664 the most probably culprit. Assigning to the perpetrator John...

[anevilyak]

Fixed in hrev47838.