Btw, here is a uname -a Darwin administrators-imac.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
32-bit kernel, 64bit inodes since it is 10.6 Snow Leopard. Am I correct ? -H On Apr 29, 8:31 am, hasse69 <[email protected]> wrote: > Hej Erik, > The test platform is running 10.6 (Snow Leopard), the funny thing > was that when we tried against libfuse.so it failed to run. > When we instead changed to libfuse_ino64.so it ran fine (but with the > problem reported)? > So from what I can tell you *must* use libfuse_ino64.so on Snow > Leopard (>=10.6)? > In any case, I will try the flag mentioned, but I do not really > understand how to "choose" the correct struct stat version? > They are coming in as arguments in the callbacks, are you saying they > can be either 32 or 64 bit versions in the same > callback? I know very little about OS X (Darwin) but should not struct > stat automatically use the 64 bit version if the OS > kernel is 64 bit ? This is one of my FUSE callbacks > > static int > cb_getattr(const char *path, struct stat *stbuf) > > If this should be compatible with MacFUSE and 64 bit inodes, how would > I do that ? > Do I need some other signature like > > static int > cb_getattr(const char *path, struct stat64 *stbuf) > > -H > > On Apr 29, 8:11 am, Erik Larsson <[email protected]> wrote: > > > Hello (Hej) Hans, > > > hasse69 wrote 2011-04-29 07.42: > > > > Thanks for the update. > > > Your description is aligned with what I see. But as I said, the > > > "double" file does > > > not exists and this is also what my application returns, fine, but > > > then I would expect > > > a readdir() call being made for "/". But it is not which mean the > > > folder contents is > > > never checked. This is the error. All the logic for parsing contents > > > of the source folder > > > and presenting it in the target folder (mount point) is done in my > > > readdir() callback. > > > I understand that Linux and Darwin are very different but this does > > > not seem > > > correct no matter what. > > > I have not tested yet but I saw that I missed out compiling using the > > > -D__DARWIN_64_BIT_INO_T=1 flag. Maybe that is causing issues? > > > I you are running Mac OS X 10.5 or compiling against its SDK, you would > > need to supply -D__DARWIN_64_BIT_INO_T=1, or the fuse_ino64 library and > > your file system would have different ideas about the layout of struct > > stat, leading to obvious errors. > > I'm not sure that it would be needed when compiling against 10.6. 64-bit > > inodes are the default in Snow Leopard. However, it's always best to > > specify this explicitly. > > > > I do not know in what way the use of 64-bit inodes might affect my > > > application. > > > It affects the layout of struct stat so you must make sure that if using > > 64-bit inodes, you also use the correct version of struct stat in your > > FUSE file system. > > > > Also, should I try the other MacFUSE distribution as discussed below? > > > [http://code.google.com/p/macfuse/issues/detail?id=406] > > > Not necessary if you're not running the 64-bit kernel (apparently > > MacFUSE loads for you, so I don't think you need it). > > > Regards, > > > - Erik > > > > On Apr 29, 4:13 am, Sam Moffatt<[email protected]> wrote: > > >> Mac OS X does not behave the same way as Linux being a completely > > >> different kernel (Mach vs Linux). In this particular case it is > > >> looking for an Apple double file which is normal. Your file system is > > >> not HFS or HFS+ and it is looking for extra metadata that might exist > > >> in the resource fork. Finder also looks for special files directly > > >> without bothering with other operations first as well. Just return > > >> that the file does not exist and it should handle it fine. > > > >> Please see this article on Apple Double > > >> files:http://support.apple.com/kb/TA20578 > > > >> What is your actual error? > > > >> Sam Moffatthttp://pasamio.id.au > > > >> On Thu, Apr 28, 2011 at 7:43 PM, hasse69<[email protected]> wrote: > > >>> Hi. I recently ported a Linux FUSE (2.7.4) fs to also support MacFUSE. > > >>> The fs works in such a way that a source folder is mounted on a target > > >>> folder. > > >>> They should be a reflection of each other, meaning any files in source > > >>> should also be found in target. Then there is more to it but it is not > > >>> relevant in this error scenario. > > >>> After mounting the empty target folder and doing cd into the mount > > >>> point there is a correct > > >>> getattr() call made for "/". > > >>> But then when trying to do a 'ls' there is no getattr() call for "/", > > >>> instead there is a getattr() call for "/._." ?? This file does *not* > > >>> exist. That would be ok if there also was a readdir() call being made > > >>> for "/" but it is not :( Using Linux FUSE a 'ls' command always > > >>> results in a getattr() call for "/" followed by a readdir() call for > > >>> "/". > > >>> The MacFUSE package used is MacFUSE-2.0.3.2.dmg. > > >>> It is running on Snow Leopard and is linking with fuse_ino64.so. > > >>> The FUSE fs was orignally written for 32-bit Linux. Does the 64-bit > > >>> version of FUSE put new demands on the implementation ? > > >>> Let me know what further information you would require to answer this. > > >>> -- > > >>> 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.
