Hi Kirk,
I have been there with problems with Apple Double files, xattrs and the like.
In actual fact if you don't implement xattrs MacFuse will work just fine. The
problems that you are experiencing are almost certainly down to something else.
If you want to check this out I would suggest that you start with the LoopBack
example. Just hack it so that it is set up and behaves like your own file
system - implements the same calls. Having problems like yours (pretty much
exactly like the ones that you describe) I did this and found that the LoopBack
file system worked fine.
In terms of debugging the LoopBack file system is gold-dust, or hens-teeth etc.
If you can repeat a problem with the loopback then it may be a problem with
MacFUSE - if not the problem is yours. If your file system does not work and
the loop back does (when implementing the same calls etc) then the difference
between the two is the solution to your problem.
The way that I got to the bottom of my problems was to modify my file system so
that I could write parallel calls to the loopback for debugging. That way I
could spot the differences. Small things you can spot by logging output - or
you can automate it by writing code to compare results.
I was asked off list a few months about this - in case it is of use to you I
append it to this e-mail.
Best regards
Alan
-------
I guess the most valuable thing that I learnt when working with MacFUSE was to
use the loopback tool it is trivial and understandable. You can munge and
mutate it so that it supports the same calls as your target and then test it.
If your problem does not exist in the loopback then it is bug in your code.
The actual business of parallel debugging is quite simple. The basic thing that
I did for this was to use the loopback as a starting point then for all of the
calls that I implemented in MacFUSE I kept both the original loopback code
*and* my new file system code. So if, for example, I did something like get the
attributes of a file I would get the attributes of the same file in the
loopback as my own file system. That way I can compare the attributes
programmatically =96 or simply squirt them out to the console using NSLog and
compare them manually. This is where I started. I later integrated a modified
form of the loopback into my source code so that I could turn on and off this
parallel working when I needed it with some compiler switches. I found also
backing my code surround FS onto the loopback useful as well it allowed me to
be fairly certain things like unit tests were right. Also worth mentioning is
that some situations are amenable to this approach some are not.
Some Fuse calls you will have to be a little cunning with like those that
return and/or use user data as you have to set and preserve user data for two
file systems. If I remember correctly used an NSDictionary here so I could
store away two sets of user data. I was using the cocoa interface for MacFUSE
but you could obviously do the same kind of thing if you used the C interface.
In some cases I wrote code to compare the results of the two file systems (I
did not expect the results to always be 100% the same for example my file
system had expected variance in dates, file permissions and some other things)
in some cases I had very small tests that failed and I could just compare the
output results in the debugger.
My basic idea behind this back to back debugging was that I found that the
loopback always worked, the file system that I was working had cases where it
did especially for some cases of interaction with the finder. My reasoning was
that if I could find the difference(s) then I could fix the problem(s).
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141665/direct/01/
--
You received this message because you are subscribed to the Google Groups
"MacFUSE" group.
To post to this group, send email to [email protected].
For more options, visit this group at
http://groups.google.com/group/macfuse?hl=.
