• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: FileID race detected
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FileID race detected


  • Subject: Re: FileID race detected
  • From: Karl Kuehn <email@hidden>
  • Date: Tue, 19 Jan 2010 08:43:03 -0800

On Jan 19, 2010, at 6:59 AM, Thomas Fritz wrote:

Since I have moved from Leopard to Snow Leopard, i obtain the following error, if I try to save a file on my nfs server: File could not be saved. The following error message is

Is it possible someone else is using that same directory/file from another system? Perhaps removing and creating that file at the same time?


No, just one person is accessing the file. It is possible to save it once. Afterwards I have to reboot the computer to be able to save it again.


I guess, When the file is saved, it is marked as locked until the computer has been restarted.

This error occurs only when I use "Apple"-Software like Xcode, TextEdit, ... When I use vim, emacs or thirdparty tools like Textwrangler everything works fine.

On Jan 19, 2010, at 7:51 AM, Jim Luther wrote:

Thomas, that's a known bug that is being addressed.

Knowing nothing about the bug that Jim Luther is referring to (but hoping that it is this one), it sounds very much like a problem that has cropped up a lot with Network Home directories when the ~/Library/ Cache/TemporaryItems folder (more usually along with the Cache folder) is redirected to the local drive to reduce network traffic. The problem is that anything that uses the "Safe Save" features in Cocoa (and the list you described are all good candidates. MS Word is the most commonly reported one), especially with "bundle" documents (not just a single file, but a folder that the Finder sees as a single unit). This feature works by first writing the whole bundle to the ~/ Library/Cache/TemporaryItems folder, then does a pair of moves to replace the old document (it is more complicated than that, but this is where the problem is). The bugs crop up when that move crosses a volume boundary, and if you have redirected that folder you have inadvertently broken its assumption.


The solution to it (pending Apple getting more creative about the Safe Save feature) is to make sure that ~/Library/Cache/TemporaryItems is re-redirected to the same disk as your home folder. However, if you are using 10.5 I will warn you that there is a bug that I reported in this area as well. If you re-redirect that folder too soon the loginwindow process with actually delete the folder that your re- redirection is pointing at. I have been told that this has been fixed in 10.6.x, but have not had time (or more accurately the setup) to re- check it on either 10.5 or 10.6.

I really do hope that the fix that Jim Luther is referring to is that Apple has gotten more creative with the Safe Save feature, and found a way around this pitfall. But I understand that this is a dangerous area to monkey around in.

--
	Karl Kuehn
		email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >FileID race detected (From: Thomas Fritz <email@hidden>)
 >Re: FileID race detected (From: Thomas Fritz <email@hidden>)

  • Prev by Date: Re: FileID race detected
  • Next by Date: [ot] Changing folder Finder display for Desktop
  • Previous by thread: Re: FileID race detected
  • Next by thread: Re: FileID race detected
  • Index(es):
    • Date
    • Thread