Sounds like there are some points that need further clarification. Whether *you* want an xattr-reliant feature (icons) or not, the higher layers of the OS (Finder being the foremost) *could*, at some point, try to write something to your file system that warrants an xattr/ resource fork. At that point, if your user-space file system doesn't support xattrs, the OS *will* try to fall back to "._" files. There's no "blocking" or "working around" this. 'noappledouble' and 'noapplexattr' are fine for experimenting, but that kind of automagical blocking is bound to throw off the Finder. If your file system's use case involves end users seeing it through the Finder, you really do have only the aforementioned 2 options: let "._" files be created or support xattrs. That said, the "support" could be done in some reasonable make-believe fashion.
You cannot "support" one or more specific xattrs and simply "block" others. You can, in fact, support some and leave the rest to the OS, but then we are back to the OS wanting to use "._" for those. The simplicity of your user-space file system isn't relevant here. The issue is that no matter what, a writable user-space file system will be made to look like a "real" file system, with "real" storage through MacFUSE. Therefore, the OS will try to do all the usual things to it. If your file system will be used "behind-the-scenes", you might have an easier to handle and more Unix-like situation. Amit On Feb 6, 5:11 pm, amical <[email protected]> wrote: > On Feb 6, 6:14 pm, Amit Singh <[email protected]> wrote:> Many parts of the OS > need and use extended attributes (xattrs). > > I agree and have no problem with it. > Been doing acl's & epf's long before unix "found" them. > > > You need xattrs for custom icon support. You have two choices: > > > 1. Implement xattrs natively in your file system. It's a bunch of > > work, but it's really nice to have it in a file system. > > This may be the "simplest" solution since I only want the custom icon. > I would need to know what to implement and what to ignore(?), block > (?), ... > > > 2. Let the OS use a fallback path to store xattrs. These are the "._" > > files you are seeing. Just because people call them "clutter" doesn't > > mean they aren't important. That information has to live somewhere. In > > a native-xattr file system, that information is not as obvious as a > > "._" file, but the "clutter" is still there in another form. > > Not with my poc filesystem. > > > By the way, there is a difference between ".DS_Store" and "._" files. > > "._" are used to store resource forks and xattrs on file systems that > > don't support them natively. > > Yup - know that. No problem, not an issue, just don't need them & > don't want them to be seen on the "other side" since I have no way of > making them invisible (I think). > > > One can't have one's cake and eat it too. > > I am working with a filesystem that has no idea of what bread is, let > alone cake. > It is yet another "fat" filesystem with an extension to satisfy a > niche application (a DRDOS variant I believe). > Since it is brain-dead to start with, adding any intelligence is a > waste of time, effort and will never be utilized. > > On another note - I really appreciate all (all of) you have done in > this area. > Nice to see that innovation is still alive and working. > > regards, > mt --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
