On Tue, Dec 23, 2008 at 10:08 PM, Amit Singh <[email protected]> wrote: > >> You should probably return EISDIR if it exists and is a directory, since I >> don't think directories can have extended attributes. > > Ted, you're probably thinking "resource forks". Directories can have > extended attributes.
Sorry, that's my mistake. I agree with Amit. In fact, the objective-c framework makes use of com.apple.FinderInfo on a directory in order to show custom directory icons. I had forgotten about that; I probably need more sleep :-) ted > > 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 -~----------~----~----~----~------~----~------~--~---
