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.
