Le 30/04/12 19:53, Emmanuel Dreyfus a écrit :
Jean-Yves Migeon<jeanyves.migeon%free.fr@localhost> wrote:What about backwards compat then? ENOATTR != ENODATA, so any code that used ENOATTR will now break. I remember reading that the attribute code was non-functional, and could not be used. Are we sure that there is no other place where it could be used but for another purpose?You are right. We had no formal release with working extended attributes, therefore we cannot break backwardcompatibility.
Well that pretty much settles the issue.If siding with Linux, better take the same assumptions. However, if NetBSD's extended attribute code supports FreeBSD semantic and someone expects tools to be shared between their ffs implementations then... this becomes a non-trivial choice.
What came up from the Linux vs FreeBSD extended attributes conventions? I can't remember if a clear path was chosen, and the archives do not point to anything obvious (at least to me)
-- Jean-Yves Migeon jeanyves.migeon%free.fr@localhost