Ah ha!... I had left extendedAttributesOfItemAtPath:error exactly as it was in the xcode template - however, your comment got me thinking about a related assumption I had made... what do they say about assumptions making an ass of you? ;-)
I had written some code that expected my return from contentsOfDirectoryAtPath:error: to limit the set of entities that would be requested in attributesOfItemAtPath:userData:error. Clearly a bad assumption as it's clear that Finder stats files to see if they exist even if they have not been reported in the return of the prior call to contentsOfDirectoryAtPath:error. As I have fixed roles for certain levels of the 'directory' hierarchy, I was just returning the type (regular file) that all entities would have at that level - but of course this is indicating the presence of the named entity. D'oh! The extendedAttributesOfItemAtPath:error is a herring rouge. I had left it as it was in the xcode template: return [NSArray array]; I don't think this is going to be a problem. Thanks again. On Dec 23, 7:30 pm, "ted bonkenburg" <[email protected]> wrote: > On Tue, Dec 23, 2008 at 6:22 PM, Luke <[email protected]> wrote: > > > 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. > > I would guess that you are returning something from > extendedAttributesOfItemAtPath:error: that would suggest that the > directory/file exists. The Finder is trying to find a unique name for > the newly created directory, so it is searching for proposed names to > find one that doesn't exist. You should return ENOENT from > extendedAttribtesOfItemAtPath: if the entity does not exist. You > should probably return EISDIR if it exists and is a directory, since I > don't think directories can have extended attributes. > > Let me know if that fixes it. > > ted > > > > > 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 -~----------~----~----~----~------~----~------~--~---
