A friend was having trouble using
cp to copy a disk image (a sparsebundle to be precise). I figured out that the line he was using copied all of the /contents/ (sparsebundles are packages, i.e. directories treated like files in GUIs) to the new directory rather than copying the sparsebundle itself.
I later created a sparsebundle on my computer to experiment with
cp and reproduced the behavior he got. Subsequently, the Finder and Dock began treating
/tmp like a file. Clicking on the entry I'd made for it in the sidebar would open a Terminal window with
/tmp ; exit; (which would fail, of course, because
/tmp is a directory). I could still use the Stack like normal, except for the
Open in Finder option at the bottom, which would try to execute it.
Curiously enough, I could still open
/tmp in the Finder by opening a subdirectory and using the
Go > Enclosing Folder command (command+up arrow). I was also able to access it normally through the command line.
I tried removing and recreating the sidebar entry and Stack, but all that did was cause the Dock to show it as a file and try to execute it immediately when I clicked on it. I then tried rebooting to clear it out; it did seem to be cleared as normal, but that didn't affect the problem.
Can anyone shed some light on this issue?
UPDATE: I thought to try
ls -l, which had an @ at the end of the permissions field. I found that it had a
com.apple.FinderInfo extended attribute, though my attempts to read it only got me this:
00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Deleting the extended attribute (
xattr -d com.apple.FinderInfo /tmp, as myself, no elevated priveleges) seems to have fixed this, though from what I can tell from my quick search about it, it might have other, negative consequences (and I'm not sure if there was a
com.apple.FinderInfo attribute there before...). I would still like an answer as to what might have happened and why I got this behavior.