Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#11193 closed bug (fixed)

Tracker won't copy symlinks

Reported by: humdinger Owned by: anevilyak
Priority: high Milestone: R1/beta1
Component: Applications/Tracker Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by 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.

Change History (9)

comment:1 Changed 5 years ago by 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.

comment:2 Changed 5 years ago by 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.)

Last edited 5 years ago by humdinger (previous) (diff)

comment:3 Changed 5 years ago by humdinger

Description: modified (diff)
Summary: Tracker won't copy hard linksTracker won't copy symlinks

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.

comment:4 Changed 5 years ago by anevilyak

Priority: normalhigh
Type: enhancementbug

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

comment:5 Changed 5 years ago by waddlesplash

Milestone: R1R1/alpha5

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.

comment:6 Changed 5 years ago by humdinger

Owner: changed from axeld to jscipione
Status: newassigned

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

comment:7 Changed 5 years ago by anevilyak

Owner: changed from jscipione to anevilyak
Status: assignedin-progress

comment:8 Changed 5 years ago by anevilyak

Resolution: fixed
Status: in-progressclosed

Fixed in hrev47838.

comment:9 Changed 5 years ago by pulkomandy

Milestone: R1/alpha5R1/beta1
Note: See TracTickets for help on using tickets.