> I don't see that it would be an ntfs-3g issue, since the exact same
> version of ntfs-3g works well in 0.4.0 but not in 1.0.0.
File systems are such extremely complex beings that it's never wise to
conclude based on circumstantial evidence.
Perhaps it wouldn't be an exaggeration to say that the biggest
adversary of MacFUSE is the Finder. Many, if not all, Mac users think
of a file system as "what you see in the Finder". This sucks, because
the Finder can be extremely bad at playing nicely with anything except
Apple's own file systems. Beyond bending over backwards to the
Finder's whims and bewildering demands (to put it mildly), there's
nothing one can do as a file system developer. It's really, really
annoying.
MacFUSE 1.0.0 returns more information than 0.4.0 from the kernel
about file system objects. One of the pieces of information is the
parent node ID of an object. The Finder can easily get quite unhappy
if it doesn't like what it sees, even if things would be fine if it
just went about its business without throwing a fit.
In your case, ntfs-3g is using the "use_ino" option internally. This
tells the user-space library to send ntfs-3g-provided inode numbers
for files and folders. This is a good thing in general, and is
desirable for such file systems. Except there is *one* problem: if
MacFUSE sets the parent node ID of the volume's *root* as something
that makes the Finder unhappy, you see the grayed "no smoking" sign
when you try to copy something out of the volume in question. Quite
nonintuitive, eh? I can imagine people trying to figure out what's
wrong, if anything, with their permissions, with MacFUSE, or with
ntfs-3g, etc.
I don't have the time to set up and test ntfs-3g, but you should tell
me if simply removing the "use_ino" option from ntfs-3g.c causes the
"no smoking" sign to go away and things to work properly.
However, the solution isn't to remove "use_ino" permanently from
ntfs-3g: the user-space file system shouldn't be forced to return some
particular inode number for some object. This could/should be handled
in the kernel. In fact, I already handle this very weirdness to some
extent in MacFUSE. See fuse_internal.h, and look for the comment that
says "bit too interesting". The check right now is:
if (in_vap->va_fileid != FUSE_ROOT_ID) {
...
}
It can be better written as the following:
if (!vnode_isvroot(vp)) {
...
}
I'll add it for the next MacFUSE release. There should be a new point
release sometime soon.
Amit
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"macfuse-devel" 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-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
