Icon? file on OS X desktop

Question

When I ls my Desktop from terminal (by using ls ~/Desktop), I see a file named Icon?. As far as I can tell, it's empty (nano Icon? shows nothing). It doesn't show up on my actual Desktop, and open Icon? shows the Finder alert

This item is used by Mac OS X and can't be opened

Here is the output from mdls Icon?:

kMDItemContentType         = ""
kMDItemFSContentChangeDate = 2009-09-23 13:32:52 -0600
kMDItemFSCreationDate      = 2009-09-20 07:27:46 -0600
kMDItemFSCreatorCode       = "MACS"
kMDItemFSFinderFlags       = 16384
kMDItemFSHasCustomIcon     = 0
kMDItemFSInvisible         = 1
kMDItemFSIsExtensionHidden = 0
kMDItemFSIsStationery      = 0
kMDItemFSLabel             = 0
kMDItemFSName              = "Icon "
kMDItemFSNodeCount         = 0
kMDItemFSOwnerGroupID      = 20
kMDItemFSOwnerUserID       = 501
kMDItemFSSize              = 0
kMDItemFSTypeCode          = "icon"

Does anyone have an idea as to what this is?

Solution 1

What is it?

It's name is actually Icon\r, with \r being the carriage return 0x0D. If letting the shell autocomplete the path in Terminal, it yields Icon^M, ^M being \r.

Icon^M is a file existing in all directories that have a custom icon in Finder. If you change a directory's icon e.g. in its Get Info dialog by pasting an image into the icon in the upper left corner, the Icon^M file is created.

^{Changing a volume's icon creates a hidden .VolumeIcon.icns file instead.}

Why is it invisible?

It's invisible in Finder, because its hidden attribute is set.

$ ls -lO Icon^M 
-rw-r--r--@ 1 danielbeck  staff  hidden 0 24 Apr 23:29 Icon?

Change with chflags nohidden Icon^M.

Where is its data?

While the file's data fork (i.e. content) is empty (i.e. a file size of 0 bytes in Terminal), the actual icon data is stored in the file's resource fork.

$ ls -l@ Icon^M
    com.apple.ResourceFork  350895 

You can copy the resource fork to a file (to view e.g. in a hex editor) like this:

$ cp Icon^M/..namedfork/rsrc Icondata

How can I view it?

The easiest way to get the image is to copy the icon from the Get Info dialog of the folder it's contained in into the clipboard, and then create a new image from clipboard in Preview (Cmd-N). It's an icns image then by default.

Its format is icns, encoded as an icon resource with derez. If you open it in a hex editor and remove the first 260 bytes (so the file begins with the icns magic byte-string), you can open it in Preview.app. Alternatively you can open it with XnView

Solution 2

An Icon? file inside a directory contains a custom icon image for that directory. The image itself is stored inside an extended file attribute, specifically, com.apple.ResourceFork, which is why the Icon? file appears to have no length.

You can retrieve that data with $ xattr -p com.apple.ResourceFork Icon? or view all extended attributes with $ xattr -l Icon?

On Snow Leopard, at least, they appear to have been phased out for system icons (In the case of ~/Desktop/, that icon would be visible when viewing your home directory in icon view.) but for the two custom directory icons I have on my system, it still exists.

Solution 3

What is it?

It is the file that stores the Image for your Folder Icon, I was only able to get this to be created if I manually loaded an image to the folder. I don't have these on my system by default.

How To Find the Icon^M files

NOTE:

This is not the same as .icns file extension.

Should you be paranoid about if finding a false positive then use:ctrl+v ctrl+m instead of ?

#!/bin/bash
# =============================================================================
# MAC OSX HIGH SIERRA 10.13.4 (17E199)
# Terminal: Version: 2.8.2 64-Bit (Intel): Yes
# Terminal Location: /Applications/Utilities/Terminal.app
# =============================================================================

echo 'Searching Documents for Icon files...'
find ~/Documents -type f -name 'Icon?' -print;

How To Create the Icon^M file

1. Open Finder
2. Right Click On a Folder
3. Press & Hold Option on your keyboard
4. Select Show Inspector
5. Drag an image to the top left folder icon.
6. Run ls -lah on that directory
   1. You should see:
      • -rw-r--r--@ 1 username staff 0B May 13 22:23 Icon?

How Remove the Icon^M file

Should you need to remove it for any reason... say accidentally on purpose testing it.

#!/bin/bash
# =============================================================================
# MAC OSX HIGH SIERRA 10.13.4 (17E199)
# Terminal: Version: 2.8.2 64-Bit (Intel): Yes
# Terminal Location: /Applications/Utilities/Terminal.app
# =============================================================================

echo 'Removing Icon files from Documents...'
find ~/Documents -type f -name 'Icon?' -print -delete;

Reference from my post on another question:

How can I delete empty folders in Mac OS X?

Solution 4

The Icon^M file is a hidden macOS system file that manages a custom image for the containing folder. However, users may find these files created for other reasons.

For example, the macOS version of Google Drive would create an Icon file in every folder in order to track sync status.

You may safely delete these files. While in Terminal, from the parent directory, run the following command: (be sure to insert the ^M with the ctrl-v, ctrl-m keystrokes):

find . -type f -name 'Icon^M' -exec rm -f {} \;

View more solutions

Comments

[JeremyKun]

The real question is: is there a way to stop the operating system from creating these damn files in every directory? It really annoys me that they show up in Dropbox.

[Motti Shneor]

These files are NOT created automatically "in every directory" unless you have some nasty software that causes their creation. Also - they may annoy you, but they have their functionality too. This the implementation of "Custom user-icon" in MacOS. If user elects to paste any image of his liking to serve as the icon of some file or directory - it will end up as a hidden iCon? file. Deleting them simply removes the custom icon.

[HikeMike]

The "system icons" have never created an Icon^M file as far as I know. Rename these special folders with custom icons (easiest to do with ~/Applications, as it doesn't exist by default anyway) and their icon will change with it.

[NReilingh]

@Daniel Yup; I suppose OP has a customized icon for his Desktop folder, then.

[Lukasa]

Apple actually do this hiding of their data in a resource fork quite frequently. I can never decide if it's neat or misleading.

[JdeBP]

It's consistent. Icons after all are resource fork contents.

[HikeMike]

@JdeBP I mention the inconsistency with volume icons in my post. I don't want to see what inconsistency would look like then ;)

[JdeBP]

You miss the wood for a single tree, grasshopper. Look beyond a volume icon file to the great forest of cases where, traditionally in MacOS at least, icons are to be found in resource forks. If you're trying to be all modern and hip and we-don't-need-no-steenking-resource-forks-we're-Unix-now, you should really correct your answer to use the modern and hip /..namedfork/rsrc suffix instead of the one that generates a warning message. (-:

[HikeMike]

@JdeBP I don't care one way or another about the resource fork icons, but it's still inconsistent with .VolumeIcon.icns. Thank you for the ..namedfork hint, but I don't get a warning from File/rsrc. I read that I should, but where does it appear?

[JdeBP]

My amazing psychic powers tell me that all of these printfs go to the system log.

[HikeMike]

@JdeBP Your amazing psychic powers are broken. I checked the system log even before commenting yesterday. It's actually the kernel log.

[JdeBP]

They are one and the same with many people's actual syslog.confs on MacOS. The kern.debug facility messages generated by printf are directed to system.log. Don't believe the example configuration file in Apple's documentation.

[HikeMike]

@JdeBP If you're referencing that post's first comment, the line following that one, at least in my /etc/syslogd.conf is kern.* /var/log/kernel.log. Since you link to xnu sources, it's reasonable to assume that these printfs end up in kernel.log via kern.*, no? I didn't believe some man` page, it's where the messages are actually logged on my system...

[JdeBP]

All these printf messages without explicit prival prefixes come out of the kernel as kern.debug as far as syslogd is concerned, grasshopper. That you yourself may not send kern.debug to system.log does not change the truth of the many people who do. The earnest seeker for truth that can use a WWW search engine to look for the syslog.confs of others will find true enlightenment. (-:

[Jonny]

I had to delete the custom icon of a folder to get that folder into SVN...

[Lake]

@Lukasa - It's consistent (as JdeBP noted) but it's also historical. The collision of NeXT and Classic MacOS meant many hard decisions about which conventions to keep, which to discard, and when to attempt both. Resource Forks on OS X were more painful until they were moved to Extended Attributes (John Siracusa's OS X 10.4 Tiger Review's section on their introduction).

[ma11hew28]

Should I add it to my .gitignore file?

[gbarry]

+1, since "How to Remove" missing from the accepted answer. And no, they're not useful when accessed from Windows, via minGW's bash.

[jan deeg]

@DanielBeck "copy the icon from the Get Info dialog of the folder it's contained in into the clipboard" How do you do that?

[David J.]

For Zsh at least, I use `Icon$'\r' for the correct filename.

[David J.]

For Zsh at least, I use `Icon$'\r' for the correct filename.

[David J.]

Using ? leads to unnecessary positives. Be more precise by using ANSI-C Quoting. For example: find . -type f -name $'Icon\r' -print;

[David J.]

The current command, which uses -name 'Icon?', may give false positives. Combined with the -delete action, it is not safe. Having -type f is a step in the right direction but not sufficient. Just because the likelihood of false positives may 'seem' small does not make the command safe. A better alternative exists: specify the filename precisely with ANSI-C Quoting, as I mention above: -name $'Icon\r'

[RexYuan]

Why would they choose to put a trailing return \r in the filename?