Ask Different is a question and answer site for power users of Apple hardware and software. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there any way to force Finder to refresh its in-use information for gray (inaccessible) files?


I move infrequently used files from my Mac (OS X 10.6) to a Windows Server 2008 file server. I have recently found a large number of files which OS X's Finder shows as gray (like it would if the file was in the process of being copied). The files in question are all valid and complete: no corruption or missing data; in fact, I can access the files from Terminal or from a Windows computer without problem, but Finder still thinks they should be considered inaccessible.

I can "fix" the problem by copying the original file to a new name, deleting the original file, waiting a minutes or so, and then renaming the new file to the original name (if I don't wait long enough, the new file will become gray when it is renamed to the original name).

Basically, it seems as if the Finder has failed to clear some "in-use" or "incomplete" flag [conjecture].

So, back to the original question: how can this be fixed? Ideally, I would like to be able to scan the network drives and find and fix all the gray files via Terminal or Recursive operation, so I can fix them all without wasting a lot of time.

share|improve this question
Does it have to do with permissions? Have you checked that? – Martín Marconcini Mar 6 '11 at 7:01
Does restarting the Finder work? – Itai Ferber Mar 7 '11 at 0:42
Not permissions: the offending files are accessible via Terminal. Restarting OS/X has no effect. – Robert Altman Apr 12 '11 at 20:39

This solved it for me!

So, what happened? It appears that the folder's creation date was set to a random date in 1943. While we are unsure of how it happened, we did figure out how to fix it.

We used a few binaries that came with the Developer Tools, GetFileInfo and SetFile. GetFileInfo showed us the creation date of the folder. We overlooked it at first, but with closer examination it caught our eye.

$ GetFileInfo Test/ directory: "/Users/user/Desktop/Test" attributes: avbstclinmedz created: 06/13/1943 06:13:00 modified: 06/13/2011 15:07:33

We then could change the creation date using the SetFile tool.

$ SetFile -d 06/13/2011 Test/

After seting the date back to a reasonable time, we can see that it has truly changed.

$ GetFileInfo Test/ directory: "/Users/userid/Desktop/Test" attributes: avbstclinmedz created: 06/13/2011 06:13:00 modified: 06/13/2011 15:07:33

The folder then showed properly in the Finder and was again usable. We also found that if you created an alias of the folder, you could see the data and move it out. Once it was moved out into another folder, the old folder could be deleted.

share|improve this answer
This would make a lot of sense; if I recall correctly, I was seeing strange dates. Unfortunately (for testing the theory), I have since cleaned up the errors and I haven't seen this again in a while. Thanks for the info! – Robert Altman Aug 16 '11 at 17:56

I solved this by using the duplicate command on the grayed out folder. The new folder will be accessible and the files can be moved to another folder. After moving the files, delete both folders (gray and copy), now both empty

share|improve this answer

Try deleting your caches (~/Library/Caches) and restarting. My experience has been that this usually fixes odd icon-related issues.

share|improve this answer
Unfortunately, this had no effect. – Robert Altman Apr 12 '11 at 20:40
up vote 0 down vote accepted

Eureka! I figured out what is causing the problem.

The files are being copied to a Windows Server 2008 network share with DFS replication (to another server). Somehow, Finder is caching the "busy" status of the file; and this sometimes occurs while the file is being replicated.

The work-around is to use terminal to duplicate the file, delete the original, WAIT!!!, and then rename the duplicate to the original name. (If you don't wait, the duplicate my become grey when it renamed.)

That is the "what"; I'm still hoping someone can explain where the information is cached.

If anyone can figure out where the information is cached and how to identify which files are affected in a script, I will accept their answer; otherwise, I'll mark this as this answer and write the problem off to OS/X & Windows interoperability weirdness.

share|improve this answer

You can try to rsync the files again by using rsync tool:

$ rsync -autN /source/* /destination

or (if there are too many files):

$ find /source/ -name \* -type f -exec rsync -atN {} /destination/ ";"

Here are the arguments:

-a, --archive               archive mode; equals -rlptgoD (no -H,-A,-X)
-u, --update                skip files that are newer on the receiver
-t, --times                 preserve modification times
-N, --crtimes               preserve create times (newness)

If this won't help, try without -u.

share|improve this answer

Your Answer


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.