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
-~----------~----~----~----~------~----~------~--~---

Reply via email to