Tracker copy stalls if it hits a FIFO

[Pete]

I've been using named pipes for a few things, and I typically just leave them sitting around. However, I'll go to copy a directory containing a FIFO, and the copy just stalls when it hits it.

Worse, I can't find any way to cancel the copy, except to reboot.

I think that the copy procedure could just ignore FIFOs, or if not, pop up an alert to either skip or cancel.

[bonefish]

Do you mean you cannot kill Tracker? That would be an (additional) kernel issue.

[Pete]

Replying to bonefish:

Do you mean you cannot kill Tracker? That would be an (additional) kernel issue.

Oh, sorry -- no. Yes, killing and restarting Tracker would be an alternative, but I guess I think rebooting is just about as quick! (:-/)

And I should make it clear that the Tracker as a whole is not locked. Just the 'Tracker Status' window.

BTW, a related issue that I hadn't picked up on before: FIFOs don't show up as files in a Tracker window, so they can sit there as traps for the careless!

[i80and]

Tracker seems to take a similar stance towards special files as does macOS Finder: ignore them (except in the case of directory deletion). This patch applies this stance towards copies.

I played with the alternative approach of warning when tracker encounters a special file while copying, but that seemed unnecessary, and would require string translation.

[axeld]

Thanks for the patch, it looks good. Could you please recreate it using git format-patch? At least I'm unsure how I can apply it (git am --signoff < tracker.patch doesn't work). How did you produce it? Your patch to #12365 seems to be in the same format.

[i80and]

Sorry; I've only previously submitted patches using Github PRs and CVS diffs.

Regenerated with git format-patch!

[axeld]

You're welcome! Applied in hrev50879.