Hej Erik, Good info. I was a bit confused but I think many things starting to fall in place. I am too much into Linux to really get this the first time. I have always used the stat64 (implicit since I use the large file support in glibc). Using the LFS, struct stat automatically is translated as a stat64 to accommodate files > 2GB. But if I understand you correct there is an additional define needed for Darwin. I do not have the include tree at hand but I trust you on this one ;) I also understand the decoupling of 32-bit/64-bit kernels and the use of 64-bit inodes, same same as Linux but only different :) I have not used -D__DARWIN_64_BIT_INO_T=1 in combination with -lfuse. But since it is compiled against 10.6 my guess is that it should be on by default, and that is also why it fails miserably when not using - lfuse_ino64.
So, then, the question then remains, why does not FUSE generate the readdir() callback when doing a 'ls' inside the mount point? When I enter the mount point (cd) there is a getattr() call made for "/", but then when doing 'ls' there is a getattr() call made for the funny "/._." (explained above). But that is it :( My callback returns - ENOENT in this case since the folder does not exist. Maybe it would help if I got a fuse level trace using -d ? -H On Apr 29, 9:03 am, Erik Larsson <[email protected]> wrote: > hasse69 wrote 2011-04-29 08.31: > > > 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)? > > No, you don't have to do that when compiling in 10.6 or against the 10.6 > SDK. You can use the regular fuse library but then you must make sure > that the file system is compiled with -D__DARWIN_64_BIT_INO_T=0 . > Simply put, these are the valid combinations: > > -D__DARWIN_64_BIT_INO_T=0 -lfuse > -D__DARWIN_64_BIT_INO_T=1 -lfuse_ino64 > > > In any case, I will try the flag mentioned, but I do not really > > understand how to "choose" the correct struct stat version? > > __DARWIN_64_BIT_INO_T is the #define that affects which version of > struct stat you get. Read through /usr/include/sys/stat.h for more info. > > > 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 > > No, the usage of 64-bit inode numbers is independent of what kernel is > used. Otherwise you would need to compile programs specifically for each > kernel flavor... that would be a mess. :) > This is about what version of struct stat the library (libfuse) uses. > The library communicates with the kernel extension and takes care of > those details. > > > 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) > > No the first one is fine. > > Since you also tried linking with -lfuse, I don't think your problem is > related to the 64-bit inodes. > > Regards, > > - Erik > > > 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.
