Tell me more ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.
up vote 2 down vote favorite

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.

share|improve this question
Isn't /tmp on OS X a symbolic link to private/tmp, try updating the path to /tmp/ (with the extra / at the end) – emcconville Aug 14 '12 at 15:50
xattr -ls /tmp shows a 40 instead of 20 for me in com.apple.FinderInfo. – Daniel Beck♦ Aug 14 '12 at 16:56
@emcconville Yes, it is, but I've always used /tmp and it's worked for me up until now. In any case, the Stack and sidebar entry were created by dragging and dropping the folder icon at the top of the Finder window, so they should point to /private/tmp anyway. – Blacklight Shining Aug 17 '12 at 5:31

1 Answer

up vote 2 down vote accepted

The "20" in the FinderInfo xattr indicates that the bundle bit is set. The bundle bit tells the Finder to display the folder as a file, rather than a folder. I suspect this attribute was copied from the sparsebundle (which is really a folder, but the Finder displays as a simple file). So what you're seeing is more-or-less expected behavior with that flag set.

share|improve this answer
Do you have a reference for the com.apple.FinderInfo values? – Daniel Beck♦ Aug 14 '12 at 16:57
2  
@Daniel: Sort of. In practice, I ran xattr -l on a folder I knew has the bundle bit set. In theory, you can figure it out from the open source Finder headers, especially the FileInfo and FolderInfo structs (which say where the finderFlags are in the overall structure) and the enum that defines kHasBundle = 0x2000. BTW, the 40 that should be there is the kIsInvisible flag, which can be set with sudo chflags -h hidden /tmp – Gordon Davisson Aug 14 '12 at 17:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.