can not see mounted filesystem in finder

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install macfuse 
2. Install gluster as per the documentation
3. Mount a gluster filesystem (assumes you have a gluster cluster somewhere)

What is the expected output? What do you see instead?
The mountpoint works as expected and you can read and write files and create
files, etc. However it does not work in finder or any other graphical 
interface, 
only from the command line. 

What version of the product are you using? On what operating system?
MacFuse1.7 on Mac OS X 10.5.4 on intel (macbookpro)

Please provide any additional information below.
 There was a gluster developer who informed me that changing the translator
in gluster (which would add the "local" option to FUSE) may work, but this had 
erratic and crashing behaviour. 
When it is mounted it looks like:
glusterfs on /data (fusefs, local, noexec, synchronous)
And an ls on / yields
drwxrwxrwx@ 51 root  wheel      4096 Jul 31 09:13 data
However, it does not show up in finder or search. Mounting it in a directory 
that finder "sees" (like my home dir) yields the same results. 

Original issue reported on code.google.com by badd...@gmail.com on 31 Jul 2008 at 6:16

[GoogleCodeExporter]

http://code.google.com/p/macfuse/wiki/FAQ

Original comment by si...@gmail.com on 31 Jul 2008 at 8:01

• Changed state: Invalid

[GoogleCodeExporter]

This is not covered in the FAQ. 

If you read carefully, this is NOT the same issue as the 
"Why do MacFUSE volumes show up with "server" (or "network volume") icons?"  
issue. 
It is also NOT the same issue as the
"Q 4.2. I mounted a MacFUSE volume but I don't see a volume icon on the 
Desktop. Why?"
And finally it is NOT the same issue as the 
"Q 4.3. On Mac OS X "Leopard", I mounted a MacFUSE volume but I don't see a 
volume icon in the Finder's 
sidebar. I've looked at all relevant Finder preferences, but still nothing. 
What's happening?"
issue.

The difference is that if I mount it in say /Users/Someuser/data finder will 
see it as an
"alias" that it has no idea how to handle. Mounting it with the -o local option 
does NOT
fix the problem...

Thanks for invalidating my valid claim. I state again, if you mount it, even 
with the -o local
option, and then try to use it in any GUI application (not just finder) you 
will find that it
thinks it is an alias, and that it needs to be repaired, but it can not repair 
it. Do you have
any knowledge of how I can fix or debug this behaviour? 

Thank you. 

Original comment by badd...@gmail.com on 31 Jul 2008 at 10:58

[GoogleCodeExporter]

> Thanks for invalidating my valid claim.

I invalidated the issue report. A valid claim isn't necessarily a valid issue 
report.

There are at least two layers of non-MacFUSE software between you and MacFUSE: 
the Finder and the "gluster file system". I 
invalidate an issue if I consider it as something that I can't address within 
MacFUSE. The file system data and metadata, 
which the Finder sees, mostly comes from the user-space file system. Unless an 
issue exists across all user-space file 
systems, it's unlikely to be because of MacFUSE. So, the first step for you 
should be to investigate this with the author(s) of 
the user-space file system. If you can demonstrate it to be an issue with 
MacFUSE itself, sure, I'll investigate. I have very 
limited time to do this type of support. (Remember, MacFUSE is *free* and *open 
source*.)

> Mounting it with the -o local option does NOT fix the problem...

And you shouldn't really be using the -o local option. I don't advocate the use 
of -o local.

> Do you have any knowledge of how I can fix or debug this behaviour?

The behavior isn't necessarily incorrect. The Carbon File Manager will, in 
fact, show a mount point within a directory as an 
alias (specifically, a "synthetic" alias). This is another ugly wart from 
marrying two semantics (BSD and Carbon File 
Manager). In BSD/unix, you can mount anything anywhere, and it's OK to go to a 
directory and be in a different volume 
altogether. In Carbon, you'd need to pretend that there's an alias. If 
everything is working properly, clicking on this alias 
should take you within the volume as expected. Perhaps something is up with the 
extended attributes as coming from the 
user-space file system. You'll have to experiment. Try mounting another MacFUSE 
file system (sshfs or fusexmp_fh), and 
compare the metadata and xattrs of the mount points.

Original comment by si...@gmail.com on 1 Aug 2008 at 12:15

[GoogleCodeExporter]

Found that the issue was with GlusterFS itself as it was not handling the Finder
specific xattr properly. 

Any developer want to use fuse lowlevel APIs directly in their filesystem, 
please
note that you either have to use "-o auto_xattr" (for easier solution) while
mounting, or handle 'com.apple.FinderInfo' xattr properly on '/' inside your 
filesystem. 

If you are using macfuse provided libfuse functions, you don't hit this 
situation as
its already handled inside libfuse getxattr.

Fix for this will be available with GlusterFS newer releases.

Original comment by ama...@gmail.com on 5 Aug 2008 at 8:37

[GoogleCodeExporter]

amarts, I'm afraid what you're saying is both bad advice and incorrect.

> as it was not handling the Finder specific xattr properly.

The com.apple.FinderInfo issue is merely the symptom. I looked at your source. 
The problem is that you are not returning 
proper errors from your xattr functions. A file system doesn't *have* to 
support xattrs--but if it chooses to implement xattr 
functions, it must return errors that are acceptable to the system (in this 
case, to the File Manager.)

> Any developer want to use fuse lowlevel APIs directly in their filesystem, 
please
> note that you either have to use "-o auto_xattr" (for easier solution)

This issue is unrelated to whether you use the low-level API or the high-level 
API. Even if you use the high-level API and you 
choose to implement xattr functions in your file system, you will run into the 
same issue if you return the same improper errors 
from those functions.

Besides, using "-o auto_xattr" is not a "solution". That's merely hiding the 
symptoms. Nobody "has" to use auto_xattr. I earlier 
suggested that you try that option to see if the problem lies with your xattr 
functions. Using auto_xattr means that you 
explicitly don't want to handle xattrs within your file systems, *and* that you 
are OK with "._" files being used instead. More 
importantly,  it still doesn't absolve you from having to return proper errors 
from *other* parts of your file system. auto_xattr is 
not going to "solve" other cases for you.

In other words, using auto_xattr means that you don't want *your* xattr 
functions to be used. Why is that the easier solution? 
The easier solution would be for your file system to not implement those 
functions at all in the first place! And if you really do 
need to handle xattrs yourself, then auto_xattr must not be used, and we are 
back to the need for returning proper errors.

> If you are using macfuse provided libfuse functions, you don't hit this 
situation as
> its already handled inside libfuse getxattr.

That's incorrect. libfuse getxattr has no special handling for 
com.apple.FinderInfo, or for any other xattr. You *will* run into this 
problem even with the high-level API: try returning -ENODATA from your file 
system's high-level getxattr implementation.

Original comment by si...@gmail.com on 5 Aug 2008 at 5:35