Ok, I see, LFS (or whatever) is supported by default, but the use of 64-bit inodes are "extra" on top of this. Then I guess one way to find out if the inode size is relevant in this case is to to compile using -D__DARWIN_64_BIT_INO_T=0 and use -lfuse instead of -lfuse_ino64. Is there really a need for using 64-bit inodes in the first place ? I do not ever think that my fs will ever need that many files. I guess that is what it is used for. Or will I get into trouble if the inode size on source file system is 64-bit but FUSE only provide 32-bit since stat information is copied from source to the virtual target fs.
The getattr() returns 0 in case of a successful stat(2) call on "/" which I have no reason to suspect does not succeed. At least the log I have does not indicate such a problem. -H On Apr 29, 11:32 am, Erik Larsson <[email protected]> wrote: > Hall Hasse, > > hasse69 wrote 2011-04-29 10.06: > > > 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 ;) > > Note: Files > 2 GB (64-bit file sizes, etc.) are supported by default, > there is no such thing as "large file support". '-D_FILE_OFFSET_BITS=64' > does nothing on Mac OS X. > > This define is purely is about the size of ino_t... 32-bit vs. 64-bit. > No other '64-bit' stuff. > (FYI, the 64-bit ino_t version of struct stat does in fact adds another > unrelated member to struct stat, 'st_birthtimespec', that you may be > interested in filling in if you have that information.) > > > 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. > > Yes, that is correct. > > > So, then, the question then remains, why does not FUSE generate the > > readdir() callback when doing a 'ls' inside the mount point? > > No idea. :) > > > When I enter the mount point (cd) there is a getattr() call made for > > "/", > > What do you return from that getattr call? > > > but then when doing 'ls' there is a getattr() call made for the > > funny "/._." (explained above). > > This is quite normal. On filesystems that don't support extended > attributes they are emulated with the data stored in files prefixed with > '._'. So it looks for that file. A Mac OS X thing. :) > > > But that is it :( My callback returns - > > ENOENT in this case since the folder does not exist. > > File, but yes it should return -ENOENT if there is no such file. > > > Maybe it would help if I got a fuse level trace using -d ? > > Maybe. I think the key point is to double-check what you return from > getattr("/"). > > Regards, > > - Erik > > > 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.
