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.
