On Sun, 15 Jan 2012 15:21:40 -0500 (EST) Mouse <mo...@rodents-montreal.org> 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
