FileID race detected when writing to NFS directories.
| Originator: | paulbloch | ||
| Number: | rdar://7818881 | Date Originated: | 2010/04/01 |
| Status: | open | Resolved: | |
| Product: | Mac OS X | Product Version: | 10.6.3 (10D573) |
| Classification: | Crash/Hang/Data Loss | Reproducible: | Sometimes |
When writing to NFS directories users sometimes get messages like Apr 1 13:10:54 lycosa /System/Library/CoreServices/coreservicesd[25]: FileID race detected: 3503 assigned for abcbegin13.tex by external allocator is already used by abcbegin13.tex The user is editing a file with TeXshop or Xcode and when they try to save the file they get a message that the file can't be saved. The system.log shows the FileID race detected message. We started seeing this problem with Snow Leopard and it continues with the latest update 10.6.3.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
Problem still present in 10.6.5 build 10H548 (developer seed)
We've just confirmed that build 10H548 (a developer pre-release of 10.6.5) does NOT fix this problem. This is contrary to rumours on other sites to that effect.
Reproducing this problem in 10.6.4
We're seeing exactly the same issue with a fully patched (as of 4th October 2010) 10.6.4 using NFS mounted homes.
Certain GUI applications (Finder, iTunes, Firefox, Safari, etc) exhibit bizarre, unpredictable behaviour when creating/deleting files and folders on the NFS mounted home. Similar operations in "Terminal" are consistently stable. When the problem affects a GUI application, it is always accompanied by coreservicesd logging a "FileID race detected" error as above.
After some experimentation with mount options (no effect -- this is not a locking issue), different client accounts, different (including zero) home directory contents, different client images (all 10.6.4), deinstalling patches (particularly Security Update 2010-005 mentioned elsewhere as a source of this problem -- no effect), and different NFS server implementations and versions (NFSv2 and NFSv3), we have realised that this problem ALWAYS affects the first user to log into the client after a reboot. A subsequent reboot "rolls the dice" again, and the next (first) user to login will be afflicted.
On the basis that there is some process which happens during the exit and restart of loginwindow after the first user logs out, we've been experimenting with restarting loginwindow before the first user logs in, but without success. We've got an official Apple RDR report open on this problem as well, and are trying to engage an Apple SE to acknowledge the issue through our local Apple account manager.