Re: buffer cache & ufs changes (preliminary ffsv2 extattr support)

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Sun, 15 Jan 2012 15:21:40 -0500 (EST)
Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> However, I think that constitutes a good implementation of a bad idea.
> This makes a file no longer a long list of octets; it becomes multiple
> long lists of octets.  The Mac did this, with resource forks and data
> forks, and you may note OS X doesn't do it any longer.  I suspect these
> will seem like a good idea for a while, until people start discovering
> all the things they break, or that break them, and realize that they
> didn't learn from history and thus had to repeat it.

I didn't know that Apple dropped the idea, but I have always found the
idea flaky myself (and sorry for the "rant"):

- Applications may still implement and maintain metadata as they wish
  without the feature
- Requires changes to support in OS, FS, and many file manipulation
  tools
- No standard API for these, few, incompatible, restricted
  solutions/formats for archival
- Security implications (scanning tools which aren't aware might skip
  "hidden/extended" data; if ACLs are eventually implemented and are
  using these, the implementation should not only support a system
  domain, but also use IDs rather than strings (or at least severely
  sanity-check a restricted string format))
- Inevitable eventual loss of the extended data, possibly because of
  backup procedures not aware of it, moving/copying/editing files with
  non-aware/third-party tools, etc (also consider editors that save to
  another file to then rename)
- An administrative nightmare when tools such as find/locate/grep/diff
  won't disclose data that the admin might be looking for but is now in
  an extended attribute

But this is only the opinion of a user, and I could keep the feature
disabled on my systems, of course, so I don't necessarily object to
optional support for it.
-- 
Matt