Thanks Ted. Well, I instrumented some more of the delegate entry points, and I found that -extendedAttributesOfItemAtPath:error: is being called repeatedly with every increasing paths of the form: /Foo/untitled folder /Foo/untitled folder 2 /Foo/untitled folder 3 /Foo/untitled folder 4 /Foo/untitled folder 5 ...
This seems to happen before -createDirectoryAtPath:attributes:error: gets called for me to create the new directory entity. Mmmm.... -- Lwe On Dec 23, 6:01 pm, "ted bonkenburg" <[email protected]> wrote: > On Tue, Dec 23, 2008 at 4:39 PM, Luke <[email protected]> wrote: > > > I have a simple VFS that projects a few levels of directory happily > > (i.e. they appear in Finder). I've used the writable template to do > > this, and expected "createDirectoryAtPath" to be called then I do "New > > Folder" in Finder in one of these directories. Instead I get the > > beachball, with no recovery until I quit my app (in which case Finder > > says "Unexpected error" and _appears_ to recover). > > The beachball sounds odd. Usually the Finder will fail an operation > with an error message that may or may not be related to what is going > on at the file system level. Are you sure you are returning from all > of the delegate methods and not blocking in one? > > > > > I'm assuming this is a sin of omission on my part (somewhere I'm no > > making an appropriate return in my delegate), but so far this is > > eluding me - after all things seem to work right up to the point I ask > > for the new folder. > > Have you tested "mkdir" from the shell? Keep in mind that a directory > create via the Finder may actually be a createDirectory followed by a > moveItemAtPath. This is because it creates a directory named "Untitled > .." and then if you give it a name it will rename it. > > > > > BTW, I'm being asked for the attributes of a range of files that don't > > exist in my FS: > > /mach_kernel > > /DCIM > > /.Spotlight-V100 > > /Backups.backupdb > > /.DS_Store > > etc. > > > I'm just returning nil for these (with the ENOENT error) as per the > > xcode template, though for files I recognise I return (at least) the > > NSFileType attribute, per the docs. Is it safe to handle these files > > this way (I assume it's also normal to be getting these requests)? > > As far as I know, it is fine to return ENOENT for these files. It is > normal to be getting these requests. The .DS_Store may be a bit > special; it might be that the Finder wants to be able to create and > write to this file. In a past file system I think I allowed creation > and writing of .DS_Store files, but I just kept them in memory and > threw them away when convenient. > > Consider using dtrace to see what is going on with your file system. > Maybe compare that with a dtrace on the LoopbackFS. I went through an > example of using dtrace in the recent MacFUSE State of the Union talk. > It is at about time 34:40 in the talk, which can be found here: > > http://www.youtube.com/watch?v=cY8lBOSO3ak > > ted > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MacFUSE" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/macfuse?hl=en -~----------~----~----~----~------~----~------~--~---
