#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: | ||
Platform: | All |
Description (last modified by )
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 by , 10 years ago
comment:2 by , 10 years ago
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.)
comment:3 by , 10 years ago
Description: | modified (diff) |
---|---|
Summary: | Tracker won't copy hard links → Tracker 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 by , 10 years ago
Priority: | normal → high |
---|---|
Type: | enhancement → bug |
This is most likely a more recent regression, this definitely used to work.
comment:5 by , 10 years ago
Milestone: | R1 → R1/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 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:7 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | assigned → in-progress |
comment:9 by , 10 years ago
Milestone: | R1/alpha5 → R1/beta1 |
---|
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.