On Apr 6, 2011, at 16:17 , Sam Moffatt wrote: > My suggestion would be to bump up debugging and see what is coming out > to work out what Finder is actually doing. Potentially Finder is doing > an operation and is getting a strange result back somewhere and > failing.
As I was able to reproduce this with 3 filesystems, in my list of suspects the actual filesystem implementation ranks third. What else can I do to debug MacFUSE other than setting the debug flag? That one for example does not print out the accessing users id, and it doesn't print out any "filtering" based on that rule: "By default, MacFUSE limits volume access to the user that mounted the volume. Nobody, not even the superuser, can access another user's MacFUSE volume." Is this access limitation something that MacFUSE actively does, or is the trick simply that the volume isn't even visible for other users? > Finder, when it doesn't quite understand why something > failed, will occasionally give misleading messages. I've seen it throw > a permission denied like error when some of its metadata ops don't > return normally. How likely is it that a metadata problem would go away when turning on allow_others? > AFAIK Finder runs as the logged in user like any normal user > application. Finder doesn't like inconsistency and doesn't deal with > it well resulting in weirdness. I've done filesystem development for BeOS in the past and that one's Desktop was a prima donna, too :-) Regards, Peter -- 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.
