Hi Peter, >From testing with the WWDC build of Lion, MacFUSE seems to be working ok, for me at least.
Yesterday I installed : - Lion Developer Preview 4 (ie the WWDC build); - Erik's 64-bit compatible MacFUSE - XCode 4.2 Preview + iOS 5 beta SDK for Lion (build 4D5031b from the iOS dev centre). (Note this is different from the XCode build in the Mac dev centre, which is XCode 4.1 Preview 6, and comes with the iOS 4.3 SDK. Not that that should make a difference). I then upgraded my XCode project for my work-in-progress MacFUSE fs (XCode offered to update the targeted SDK etc), compiled and built and ran seemingly without issues. Have you tested with the WWDC build yet? Anything I can do to help? Regards - Rory On Apr 13, 12:45 pm, Sam Moffatt <[email protected]> wrote: > I've seen Locum before, I remember googling about it ages ago for some > reason. It's an elevated helper process for Finder and it's been > around for a while. Why the behaviour has changed is a bit strange. > Most of the googling I did just recently suggested it was mostly > involved in deleting though there are references to it handling > copying, perhaps Apple are giving it a more prominent role. I did a > copy long before and noticed it was present doing something on 10.6. > > This could be a pre-release behaviour they'll remove later (unlikely) > or something they're planning on continue doing. Looks like the only > way around it is to permit root to get at things. The only way to know > would be to ask Apple directly. As to if changing the default MacFUSE > behaviour is a good move, that is unfortunately well and truly beyond > me :/ > > Cheers, > > Sam Moffatthttp://pasamio.id.au > > > > On Wed, Apr 13, 2011 at 6:53 PM,PeterStegemann<[email protected]> wrote: > > On Apr 12, 2011, at 16:41 , Sam Moffatt wrote: > > >> Well that'd certainly answers why allow_others changes things, instead > >> of its metadata ops not returning properly its sending weird data. > >> What process is actually sending those requests on behalf of Finder or > >> is it actually the Finder process doing that? > > > Now it's getting spooky. Here's my log of dragging a file to the Desktop > > (only "bad" accesses listed): > > > -- > > Apr 13 10:46:58 gopher kernel[0]: fuse_biglock_vnop_getattr: biglock > > 0xffffff800da1e320 aquired! > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_vnop_getattr > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_blanket_deny (issuser=0, > > isvroot=0, pid=12327) > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_match_cred requestcred > > (uid=502, ruid=0, groups[0]=20, gid=0, svgid=0) > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_match_cred daemoncred > > (uid=502, ruid=502, groups[0]=20, gid=20, svgid=20) > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_match_cred ok > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_blanket_deny > > fuse_match_cred() > > -- > > Apr 13 10:46:58 gopher kernel[0]: fuse_biglock_vnop_getxattr: biglock > > 0xffffff800da1e320 aquired! > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_vnop_getxattr > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_blanket_deny (issuser=0, > > isvroot=0, pid=12327) > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_match_cred requestcred > > (uid=502, ruid=0, groups[0]=20, gid=0, svgid=0) > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_match_cred daemoncred > > (uid=502, ruid=502, groups[0]=20, gid=20, svgid=20) > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_match_cred ok > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_blanket_deny > > fuse_match_cred() > > -- > > Apr 13 10:46:58 gopher kernel[0]: fuse_biglock_vnop_getxattr: biglock > > 0xffffff800da1e320 aquired! > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_vnop_getxattr > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_blanket_deny (issuser=0, > > isvroot=0, pid=12327) > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_match_cred requestcred > > (uid=502, ruid=0, groups[0]=20, gid=0, svgid=0) > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_match_cred daemoncred > > (uid=502, ruid=502, groups[0]=20, gid=20, svgid=20) > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_match_cred ok > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_blanket_deny > > fuse_match_cred() > > -- > > Apr 13 10:46:58 gopher kernel[0]: fuse_biglock_vnop_getattr: biglock > > 0xffffff800da1e320 aquired! > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_vnop_getattr > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_blanket_deny (issuser=0, > > isvroot=0, pid=12327) > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_match_cred requestcred > > (uid=502, ruid=0, groups[0]=20, gid=0, svgid=0) > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_match_cred daemoncred > > (uid=502, ruid=502, groups[0]=20, gid=20, svgid=20) > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_match_cred ok > > Apr 13 10:46:58 gopher kernel[0]: MacFUSE: fuse_blanket_deny > > fuse_match_cred() > > -- > > > And this is process 12327: > > > root 12327 0.0 0.1 2468648 2172 ?? Us 10:46AM > > 0:00.01 > > /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Resources/L > > ocum > > > Which is, btw, temporary - it goes away when the operation is finished. I > > could only see it because I was going to replace a file and the requester > > asking me if would really want to do it paused the operation. Btw, the > > getattr and getxattr calls are issued before the requester shows up. > > > 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 > > athttp://groups.google.com/group/macfuse?hl=en. -- 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.
